When planning a sprint, I can enter a team capacity - the number of hours the team has as a whole during the sprint to work.
I can also add original estimates to tickets.
As team members log time against tickets, the remaining estimates are adjusted accordingly, so I can see how much WORK we have left.
Is there a way that I can make the system subtract the time logged on tickets from the team capacity, so that I can also see the remaining CAPACITY available?
It would be helpful to be able to compare remaining work to remaining capacity.
The idea of each person just pulls from the pile is great as long as your company has a bunch of equal drones. As soon as I have teams consisting of developers, dbas, artists, etc., this approch does not work. I need to see how much work the artist has on his plate vs that of the dba. I'm not going to ask any project manager to architect a databse for me.
I completely agree with this! I ran a development team at a previous company where we used TFS, and the capacity tracking was invaluable. Even if you only have devs to plan for, you end up with devs who are the "go to" for certain things, and so you can still end up with one person being overloaded, because they're the only person who can pick up certain tasks. In an ideal world, anyone would be able to pick up anything, but it doesn't work in reality.
I'd say if you're in situations like this then you're not planning the sprint as well as you could (i'm not saying we're not guilty of this either btw, it's the thing we're working hardest on resolving).
A way to skill up the team so they can be more "full stack" would be to encourage pair programming on a few of the stories where there is only one "go to guy". Any argument that this isn't possible isn't valid in my opinion (which is precisely that, just an opinion) - it just requires a good scrum master and some understanding from product.
No. I can see the remaining estimates. What I can't see is how much time my team has to do the work. Work days X team members - vacation days and so on.
I can't start a sprint and say in this sprint, my team has a total of 100 days and then see a line on the burndown that shows me how many of those 100 are left as we go.
My comments and several others are on this older post...thought it would help to link it: https://answers.atlassian.com/questions/108279/resource-capacity-planning-in-jira-possible
Regardless of how you slice it, this missing capability is a major headache on the Rapid Boards.
Yeah - no burn up chart is a real pain in the ass as well, it's way more useful than the burn down chart (they have it for the epics as well which means it must be able to be done).
One thing with JIRA AGILE is that does it a certain way, a way that is designed to force you to do "better agile" which isn't a bad approach, it just means it doesn't do things some people want.
For example, devs that are over allocated is a concept it doesn't support because you're (idealistically) supposed to look at the team capacity - put a column limit based on the number of devs in the team and work on the ethos that only one feature should be worked on at a time and everyone works together to sort it if one person is struggling (pair programming and the like). This approach really does rely on CI/CD and feature releases to be efficient though.
Renjith: If it is not designed for that, why was the capability always available in the Classic Planning Board?
Rule #1 of software rearchitecture: Don't remove features a large number of users depend upon. The Sprint Leads at our company are asking us to move to Rally due to this feature being removed with the new Sprint boards.
To me this sounds like you're trying to get the tool to resolve something that the team should be able to tell you themselves?That sounds argumentative but it isn't supposed to be, a bit more of an explanation is needed I think.
At the end of a sprint planning session I assume you ask the team if they think they have enough work for the sprint? Let's assume they say yes.
So as far as they are aware, the forecasted work for the next two weeks (assuming you are in two week sprints) is enough to keep them busy and there are no dependencies on other features. But this might not prove to be the case - one person might finish their stuff really quickly and another might find that one of the things they are working on is way more complicated than originally thought.
In a scenario like that it is up to that person to be confident enough to tell the team that they are struggling, which means it is up to the scrum master to nuture an environment where people are comfortable to admit these sorts of things with no risk of being blamed.
You may find that introducing WIP limits to your columns is a practice that will help you as it forces the team to focus on finishing as opposed to starting - meaning that if there is nothing in the backlog for someone else to start, or the current number of features in play is already at the maximum (based on to your WIP limit) so the dev that is free can then help the one that is struggling by pairing with them. Have a watch of this video where Henrik Kniberg explains the awesomeness of WIP limits.
Remember, Scrum often shines a light on the problems that need to be solved. It - and the tools you use to implement it - are not the solution.
Hello Atlassian Community! My name is Emilee, and I’m a Product Marketing Manager for the Marketplace team. Starting with this post, I'm kicking off a monthly series of Spotlights to highlight Ma...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot