Scrum , Velocity calculation and Sprint Calculation

Question

Following figures showing the performance of a Scrum team during the first 6 sprints of a project.

1. Sprint: 15 SP
2. Sprint: 5 SP
3. Sprint: 20 SP
4. Sprint: 15 SP
5. Sprint: 25 SP
6. Sprint. 10 SP

Question 1: What is the velocity of the team ?

Question 2: How many Story Points are likely to be achieved by this team in Sprint 7 ?

Question 3: Now if a have a table like below and represents the Product backlog . Which stories would you select for sprint 7 , and Why ?

+---------------+
| Story Id | SP |
+---------------+
| S1       | 3  |
| S2       | 1  |
| S3       | 3  |
| S4       | 5  |
| S5       | 8  |
| S6       | 3  |
| S7       | 1  |
| S8       | 1  |
| S9       | 5  |
+---------------+

Question 4: And based on above data , how many sprints are required to finish the project ?

Question 5: Draw a burndown chart for this Scrum project using the data provided in the above both of the table. What can be inferred from this burndown chart ?

Answer 1

Question 1: What is the velocity of the team ?

You already wrote it down in your question, it's simply the number of Story Points "burned" in a sprint (Velocity). So in Sprint 1 your velocity is 15. Please Not that only "done" Stories are counted. Whats more interesting is the average velocity need for question two.

Question 2: How many Story Points are likely to be achieved by this team in Sprint 7 ?

The "average" velocity is more interesting, because this will help you forecasting the velocity for upcomming sprints. This can be simply done by adding all Story Points from past sprints and divid it by the number of sprints. In your case this may lead to:

(15 + 5 + 20 + 15 + 25 + 10) / 6 = 90 / 6 = 15

Because your Velocity changes over time (you get faster, team composition changes, etc.), you may only take the last 3 sprints. Scrum Inc. recommends the Yesterday's Weather to forecast the next Sprint, also regarding the number of team members availlable.

Question 3: Now if a have a table like below and represents the Product backlog . Which stories would you select for sprint 7 , and Why ?

If the table represents a priorized backlog (this is a must in Scrum!), you would take the first X Stories depending on your estimated velocity for the next sprint.

The order only depends on the Product Owner, she / he is the only one who priorizes the backlog. There are several approaches to do this:

• Weighted Shortest Job First
• MoSCoW

Question 4: And based on above data, how many sprints are required to finish the project?

Let's take the average velocity calculated above (15SP). Your Backlog has a total size of

3 + 1 + 3 + 5 + 8 + 3 + 1 + 1 + 5 = 30SP

So in theory you might finish the project within two Sprints.

(!) But be beware that all of these numbers are estiamtions and NOT facts. Your lowest velocity was 5SP and your highest 25SP, so worst case you might need 6 Sprints or more to finish it.

Answer 2

Homework Disclaimer

There's nothing wrong with asking academic or homework questions, but asking questions where you haven't put any effort into solving the questions yourself is frowned upon. Furthermore, homework questions don't always have canonical answers because the only "right" answer is the one your teacher is looking for.

With that said, the questions you're asking are worth answering for two reasons:

1. They're relatively common questions, and good answers will provide worked examples.
2. They highlight a lot of common misconceptions, and understanding why the questions have some misleading and/or incorrect assumptions is worth pointing out.

My answers below will help you answer your homework questions more knowledgeably, but may or may not be the answers your teacher expected you to provide. Your mileage will therefore vary. Good luck with your assignment!

Calculating Velocity for Sprint and Release Planning

What's Your Velocity?

For velocity values of 15, 5, 20, 15, 25, 10 you have a median velocity of 15. There is a 90% likelihood (technically, a confidence interval) that your actual velocity for your next Sprint will fall between 5 and 25.

See the Velocity Range Calculator for the math behind this calculation. You can do your own calculations with a different confidence interval if you prefer.

What's Your Planning Capacity?

You can select any mix of stories you like, provided the total is less than the team's expected capacity and that the stories selected all relate to the current Sprint Goal. Without any fudge factors or discussions about risk tolerance for an unmet Sprint Goal, then I'd assume 15 story points as a reliable target give or take a small story.

Scrum Isn't a Knapsack Problem

Sprint Planning is partly a knapsack problem, but is further complicated by the requirement to select stories in priority order from the top of the Product Backlog and to ensure that all selected stories contribute to (or at least, don't detract from) the coherence of a singular Sprint Goal. That's why the Development Team and the Product Owner are encouraged to discuss stories and do some horse trading during Backlog Refinement and Sprint Planning meetings: to allow the Product Owner to edit and reprioritize the Product Backlog on the fly to optimize stories for team selection.

Story Selection Isn't Free-Form

The team can't pick stories based solely on size estimates, nor should stories be selected based primarily on trying to maximize the number of story points for the Sprint. In Scrum, stories must be selected by the team in strict priority order from the Product Backlog until their expected capacity for the Sprint is allocated, but it's the Product Owner's job to make sure that priority order reflects a central coherence for the Sprint.

Optimize for Cadence, Not Velocity

Accepting stories based on ordinal values up to (but never beyond) the team's capacity forecast may sound counter-intuitive, but it really shouldn't. Pragmatically speaking, Scrum teams optimize for coherence and a reliable cadence rather than velocity for its own sake. Velocity is just a proxy for capacity to assist with forecasting.

Algorithm designers strive for optimal solutions to the knapsack problem. Scrum teams strive to deliver value at a reliable cadence. Too much focus on optimizing velocity is a distinct anti-pattern.

How Long for Entire Product Backlog?

You have 30 story points remaining in your Product Backlog. Assuming you have estimated accurately and that no estimates change over the remainder of the project—teams are expected to re-estimate based on new information during Backlog Refinement and Sprint Planning—and also assuming that you don't add or remove anything from your Product Backlog over the next two Sprints, then at your present velocity it will take you at least two Sprints to complete the entirety of current backlog.

What's Your Worst-Case Scenario?

Note that since a Sprint provides a potentially-releasable increment at the end of each iteration, it's possible that the project can be declared sufficient and be closed out after the current Sprint. Alternatively, if your team delivers less than the median (your confidence interval has five story points as your low-end forecast) then it may take up to six Sprints to complete the entire Product Backlog as currently constituted.

While the real worst-case scenario is always:

• no work completed per the Definition of Done,
• a failed Sprint Goal, and
• a velocity of zero for the current Sprint,

based on statistical probability you have a 90% chance of getting at least five story points done in your next Sprint. You have to recalculate your probabilities each Sprint, but for forecasting purposes six Sprints is a reasonable outer bound given your data.

Answer 3

What is the velocity of the team ?

The team has not yet achieved a stable velocity. I wouldn't necessarily expect the exact number of story points achieved, but a variation of 10-15 story points between each sprint seems excessive. Although this may be dependent on the story point values used - I'm most familiar with using a set of 1-3-5-8-13-20-40 where stories sized at 20 or 40 need to be reevaluated to see if they can't be decomposed into smaller stories that also add value to stakeholders.

How many Story Points are likely to be achieved by this team in Sprint 7 ?

I would plan on approximately 10-15 story points being achieved in the Sprint. This is based on the guidance that you use the last completed Sprint as the point of reference for planning the next sprint. Once you achieve a stable velocity, you would likely be completing close to the same number of points every Sprint, Sprint-after-Sprint.

Now if a have a table like below and represents the Product backlog . Which stories would you select for sprint 7 , and Why ?

In the absence of a well-defined goal that can be used to select Product Backlog Items, my initial proposal to the team would be to bring in Stories 1-4, for a total of 12 Story Points. It's slightly more than completed in Sprint 6, but most Sprints achieved more than 10 (only 2 didn't). If the Product Backlog has been appropriately prioritized, these also represent the most value-adding stories to the stakeholders.

Without fully understanding why the team's velocity was low in Sprint 2 and 6, it's not possible to go beyond the simple math to determine why the team was low. It also doesn't account for changes in capacity - vacations, sick leave, team members supporting other work, etc.

And based on above data , how many sprints are required to finish the project ?

It's best not to try to answer this question unless you need to. The whole point of the agile methods is to support incrementally delivering software until the stakeholders funding the project decide that the features left in the backlog aren't worth the cost of one or more iterations. However, there may be cases where you need to attempt to estimate, such as a contract proposal for a long-term contract.

There are 30 Story Points left in the backlog. Assuming no stories are removed and none are added and based on the historical data, I would estimate between 2 and 6 sprints are required to finish the work. Of course, it depends on your confidence interval. Based on historical data, it's not likely for the team to complete two consecutive Sprints of 15+ Story Points. It's more likely to take at least 3 or 4 Sprints to finish the remaining work.