How is sprint capacity determined in JIRA Agile(Greenhopper)?

Question

I am new to JIRA Agile (formerly Greenhopper) and am scratching my head on how it determines sprint capacity for planning and burn-down estimation. From what I gather, it is assuming the sprint capacity (lets say in hours) is equal to the total demand of the issues you add to the sprint - ie if you add 40 hours of issues to a sprint, then once the sprint starts, the capacity for the sprint is 40 hours.

To me this is muddling the terms capacity and demand, if this is how it works. Also, it implies I have to use an external tool or process to do capacity planning first, then be sure to setup the sprint exactly right before starting it.

I would like to know how others are solving the capacity planning problem using JIRA and if there is a way to specifiy N-hours or story points per sprint for release planning purposes.

Answer 1

Tasks/Hours or Stories/Points is almost irrelevant when it comes to solving capacity planning in a sprint.

The benefit of using story points is purely to make it easier for your development team to estimate the stories. People are very good at estimating relative size when given something to compare against. Not so good at providing estimates based purely on past experience. When building software it is a rare thing to do something exactly the same way a second time. Even if you do see repetitive tasks involved an experienced dev team will see that as an opportunity to refactor and generalize a solution that can be reused quickly and easily thus coding a different solution than the first time through.

Step one is to determine one of the easiest tasks in your package of user stories and call it a 1 point story. From there you just need to answer the question how much harder is it to do this story compared to your "1". Once you have done this for a few stories you'll have a larger group to compare against and the estimates become easier. If you come across a story that is more than 2 levels away from any story you can compare against (eg the biggest story you have estimated was a 3 and your dev team is saying this is a 13 or larger) I would recommend leaving stories like these until you have something closer in comparison. Alternatively you could try to break down larger stories into smaller ones making it easier to estimate.

As a Project Manager all you need to do is take those story points and plan out your next sprint. "But I don't know how many points fit into a sprint!" you say... If this is a new project or a new dev team who is estimating these stories, take a few small stories, no bigger than a 2 or 3, subtask them out and have the team estimate each subtask. Add up the total hours and divide by the total points to give you a "wet finger in air" estimate of how many hours per story point your team will need. After each sprint do this same calculation to get your average "velocity" (average hours per story point).

I use the term velocity knowing that this term defined in the pure agile methodology is quite different (story points per sprint). I do this understanding that external customers always ask "How many hours is this going to take?", or "How much is this going to cost me?". Having story points converted to hours at the PM level just makes it easier to report against and talk to customers about without having to educate them on the agile methodology.

I've been working with agile software development teams for decades (both as a developer and a PM) and this is how I've managed to make it all work.

Hope this helps someone new to the game.

Answer 2

@Shane, Sprint capacity is more usefully determined by Story points than by hours . Usually, Story points are NOT converted to hours. The idea is that Story point is a better reflection of the collective average estimate of the team.

If it is the first sprint,the story points per sprint is always a guess. Based on the story points burnt down, you decide if you want to increase/ decrease the story points for your next sprint

In Agile(Greenhopper), the story points you add to a Sprint is therefore the capacity of a Sprint. The story Point field is different from the "Estimate" field