3

I'm fairly new to Scrum and its sprint planning/retro (etc), our team today was trying to calculate velocity, capacity and forecast for the following sprint, but we just realised that no one actually knew how to do this.

Could someone please explain to me (like if I were 5) - and/or point me somewhere - on how to go about doing this? I have googled, and I'm about to start reading the Scrum Guide, but I'm still at a loss.

Caveats: Since I'm still new to this I do not have too much data (1 sprint completed) and there was no velocity, capacity, etc, taken there, I understand that perhaps what I'm trying to accomplish will not be 100% accurate, but ny help will be appreciated.

Previous Sprint:

Team members: 4

Previous sprint(s) completed: 1 (2 weeks)

Previous sprint points Taken: 34

Previous sprint points completed: 13


New Sprint

Points wanting to take: 21

Sprint duration: 2 weeks

Working Days of each team member: (9 + 9 + 9 + 4.5) = 31.5 days

  • In addition to Thomas's excellent answer below; ask yourself some questions - why are you estimating in points? I mean really. It is simply because you inherited that? As a junior scrum team you could just say "how many things did we get done?" That will prob be close to the amount of things you do next Sprint barring some variation in the environment. Coach the team to take in less and leave themselves some capacity. They can always add more later if they want. Also, days do not equal points. There is no relation between man days and points. If you want to estimate in man days do so – Venture2099 Jun 21 '18 at 12:57
5

Velocity is not something that is calculated, it is measured. Velocity is the amount of work that is completed in a Sprint. In this particular case, since you estimate work in Story Points, you will have a Velocity in Story Points. At the end of a Sprint, you can look at all of the work that is Done (per the Definition of Done), sum up the Story Points and that is your Velocity for the previous Sprint.

Capacity is how much work a team can take on. In Scrum, I prefer to represent this as a percentage and only consider the members of the Development Team. If all members of the team are working for the entire Sprint, the capacity is 100%. In a 2 week Sprint with a Development Team of 5 people, if there is a company holiday and no other time off, the Capacity of the team would be 90%. I keep Capacity very high level and approximate keeping it at full days (someone taking the morning off is computed as them taking a full day off), but there are people who prefer more fine-grained capacity. When thinking about Capacity, it's also useful to consider any specialized skills that individuals have.

The concept of Yesterday's Weather can be helpful to you for forecasting and planning a Sprint. Yesterday's Weather says that your next Sprint's forecast is very likely to be closely related to the actual results of your most recently completed Sprints.

In your example, you have completed one Sprint and have a known Velocity of 13. You should plan on a Velocity of close to 13 for your next Sprint. Once you have a few Sprints completed, you can take a look at the Velocity of the previous few Sprints and use a sliding-window average. A common recommendation is to use the 3 most recent completed Sprints. However, you should also adjust for capacity.

Note that Velocity, Capacity, and Yesterday's Weather are not a part of Scrum as defined in the Scrum Guide. Scrum is silent on the methods used to plan a Sprint.

I would also recommend that you try to have more Product Backlog Items refined and ready for development work than you can bring into the Sprint. Should your team increase their performance (or perhaps the work was over estimated), you probably don't want people to be idle. They should have something to do, such as investigating and defining upcoming work or being able to get a start on the next highest priority item in the Product Backlog.

  • Thomas - I don't want to replicate your answer since it covers 80% of what the poster is asking but I would suggest adding more to yours. The OP seems to be lacking some basic patterns and is overlapping them. It might be worth splitting your answer into headers 'Planning', 'Estimation Techniques' and 'Velocity'. Most new Scrum initiates just blur it all into one. – Venture2099 Jun 21 '18 at 13:00
  • @Venture2099 I'm not sure what you mean. It already seems like they have estimation techniques (they are using Story Points) and are tracking Velocity (Sprint 1 has a Velocity in the amount of completed Story Points). This question appears to be exclusively about how to plan how much work to bring into the Sprint. I'd be more than happy to make this answer more clear, but I'm just not sure what else to include. – Thomas Owens Jun 21 '18 at 13:05
  • @ThomasOwens and @Venture2099 I've been reading online about formulas on calculating capacity, velocity, etc. Are there any useful. Do I need to use them to calculate this coming sprint? For example: Velocity = delivered points / # sprints completed Capacity = # team members * # weeks in sprint * 24hrs(60%) or 32hrs (80%) of actual work – intercoder Jun 21 '18 at 13:12
  • @intercoder OK - I'll expand on this answer. But Velocity is simply the amount of work (in your case, Story Points) competed in the previous Sprint. No calculations necessary. – Thomas Owens Jun 21 '18 at 13:14
  • @intercoder Did my edits address everything? If not, let me know and I can work it in there. – Thomas Owens Jun 21 '18 at 13:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.