0

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 - i.e. 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.

jessehouwing
  • 106,458
  • 22
  • 256
  • 341
Shanerk
  • 5,175
  • 2
  • 40
  • 36
  • Update: JIRA Agile calculates velocity based team performance regardless if you use story points or hours of effort. However, if you use time estimates, you can get a reliable man-hour estimate on your release burndown from day 1. JIRA Agile requires 3 sprints to be completed before it determines velocity. Therefore it will not be able to forecast until the velocity has been established, which tends to favor 1 week sprints so you can more quickly establish your release burndown. – Shanerk Sep 21 '15 at 13:48

2 Answers2

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 (e.g. 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.

JeffS
  • 166
  • 5
0

@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

Biswajit_86
  • 3,661
  • 2
  • 22
  • 36
  • Agile(Greenhopper) can be configured to use Story Points or Hours for the burn-down, I only gave hours as an example. The question remains the same, and it is not a theoretical question about scrum methodology but a technical question as to how the tool determines capacity (if at all). What you are describing is using historical velocity to plan how many story points go into your next sprint based on a static team. However, what if you add or remove team members? Or they can only commit N hours in one sprint versus another due to other projects coming their way? – Shanerk May 09 '14 at 16:06
  • Also, good article on using hours versus story points for sprint planning is attached below. Also note, in Agile(Greenhopper) the default functionality only lets you put story points on Epics and User Stories, not Bugs, Tasks, Features or other issue types. http://www.mountaingoatsoftware.com/blog/why-i-dont-use-story-points-for-sprint-planning – Shanerk May 09 '14 at 16:07
  • @Shane, I do not agree with the idea explained in the blog. A primary reason for picking story points is that they are a better measure of average complexity than hours. If you estimate using hours, your estimate is always skewed by the familiarity of the person who is doing the estimate. Story point helps address the issues complexity rather than the time that will be spent. – Biswajit_86 May 10 '14 at 00:41
  • You can always override the default implementation of story points across categories, however I believe story points on tasks is not a good idea. A story is always the least granular deliverable that can be accepted by the Product Owner, so it makes sense not to put story points on the tasks. – Biswajit_86 May 10 '14 at 00:41
  • Regarding planning for a sprint using historical velocity, it does not work for you in the first 2-3 sprints but after that it works really well. We have used the logic when loosing resource and swapping resources and it has worked for us well. The only challenge is that a new resource takes time to get used to the story pointing of the team. Various teams use various methods to tack this, the most simplest being gradually increasing the story points that can be attributed to that member. – Biswajit_86 May 10 '14 at 00:45
  • I will assume you are using JIRA Greenhopper in your organization. Based on what you are saying, you are determining prior to the sprint how many story points can be assigned to specific individuals, and therefore collectively to the whole team. I assume you are basing this on past performance of the individuals, except in the case of a new person. So are you doing this inside Greenhopper or in spreadsheets then using the totals to determine how many story points to allocate to a sprint? – Shanerk May 12 '14 at 14:45
  • @Shane, we are doing this within JIRA itself.Instead of going on an individual basis we decide as a team that we will achieve x number of story points in our planning session.We story point all our tasks (based on complexity) for our prioritized epics and then we create a sprint and add as much stories that we need to get to the limit x. After we have added the stories, we start the sprint . We normally finish the sprint with a day/two remaining in the sprint . PS:- We only start story pointing when we are picking up epics for a sprint. IF we are not picking up epics , we do not story point. – Biswajit_86 May 12 '14 at 23:58
  • OK, I understand this process. It sounds like you are not using JIRA to pre-determine how many story points a team (or individual) is capable of doing (i.e. the capacity) but that you are coming to agreement during the sprint planning meeting via a dialog, correct? – Shanerk May 13 '14 at 11:59