Scrum , Velocity calculation and Sprint Calculation

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 ?

• In future, ask one question per post and please show your work. Homework questions can be on topic, but you're expected to explain your own context and understanding in order to constrain the scope of the question and answers. Jul 23, 2017 at 12:31
• thanks for your comment , next time i will put some homework as well :) Jul 23, 2017 at 16:26

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:

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.

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.

Calculating Velocity for Sprint and Release Planning

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.

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.

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.

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.

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.

• How does one achieve a stable velocity? I would posit that a stable velocity is a unicorn, the finding of which is a Project Managers dream... Jul 24, 2017 at 21:40
• @MrHinshPST By consistent estimation and sizing. You can even adjust for capacity. My team has been delivering between 20-24 points for 4 sprints in a row now. Jul 24, 2017 at 21:43
• For me that would indicate something is wrong (not saying it is, just indicate); I would ask: Are the team not experimenting enough? Do you get at least 1 actionable commitment from each retrospective? When was the last time the DoD was increased in Scope? Is quality increasing? Jul 24, 2017 at 21:45
• @MrHinshPST Experimenting is good, but it has risks. When you have a date by which certain functionality is needed, consistent performance is more important. But yes, an experiment can result in a change, positive or negative, in velocity. You just need to track changes over time to watch their impact. But, yes, there are action items and increase in quality. The team has chosen to defer large experiments experiments until after the project end date. Just from a SM prospective, you need to balance improvement with consistency for management planning. Jul 24, 2017 at 21:50
• The Product Owner is accountable for value, and thus management planning. The Scrum Masters is accountable for the process, and thus it is absolutely not the Scrum Masters job to "balance improvement with consistency for management planning". The Scrum Master should be always striving to improve the team, the process, and to remove organisational impediments. Jul 24, 2017 at 21:56