Velocity, PBIs and Forecasting

By | January 14, 2018

I have to admit that I have never had good experiences with velocity, I had average experiences, I have always struggled with it, some years ago when I was developer and now more recently as Agile Coach and Scrum Master. I know that with the team getting more into Norming and Performing, with the velocity we should be able to predict better when are we gonna have something ready.

There are teams that are not giving Story Points to everything, for example, there are teams who give SP only to features because as a team they want to know the velocity of doing new software, and then, items like bugs who gives a lot of uncertainty are estimated with t-shirt sizes or different techniques, but this post is not about what to estimate and what not to estimate.

I don’t have to acknowledge that software is complex, we all know this, but, nowadays people are rotating more within companies, and not also within companies, also with models like the Spotify with the chapters and so on, people also rotate more within teams, this is something I like it of course, what I mean is that as more people rotation you have, harder for a team is to get in the Performing phase for a long time, but this post is not about that and neither about how to estimate, is about how a team can know better how much they can do also visualizing their achievements in terms of tasks every Sprint(PBIs).

The first inspiration of this came from a training I had with Jerónimo Palacios who talked us about it. After the training, I started to think a lot about it and I realized while observing the teams that every Sprint they were more accurate with how much the thought they could do in terms of numbers of tasks than with the amount of SP.

I started to search within the organization examples of velocity visualization, and I ended up talking with Mels, a trivago colleague and he gave me an example of how he was doing it, I took his example and made some changes to satisfy my needs.

In the following example what you see is a comparison of the first 6 sprints of a team I worked in the past, people and dates are not relevant so they are not present, but the data is real.

I will start showing the table for Story Points.

Start and End dates: Dates of the Sprint

Available Developer Days: This is by person, how many days will this person be available to be working on the tasks? I always remind here that we have to be realistic, during the sprint we will have meetings, Scrum ceremonies, etc.. so we have to try to be realistic about how many days each developer will have to work on tasks, you might wonder why we have names of people here, trust me, is not to control or blame or whatever, is to help to understand what happened every sprint, you will see later.

Total Dev Days: Yep, the total amount of devs days.

Feasible Story Points for this sprint: This is basically the number of Total Devs Days * by the AVG of all Velocity Per Dev Day

Story points planned: How many SP the team ended up deciding to include.

Story points completed: How many SP the team ended up delivering.

Difference SP planned vs completed: The difference of the two values above.

% of completed SP comparing to what was the plan: The difference in % of the two values above.

Over/Under Team Confidence: This is set by the team, how many SP of difference they consider as Over or Under Team Confidence, I mean, if we plan 30 and we deliver 29, was the team really too confident? too little? were they ok? I find it useful later you will see why.

Velocity Per Dev Day (sprint): This is the amount of SP Delivered / by the total Dev Days.

The finish with, at the right side you see some totals, like an overview.

I will continue showing the table for Items Overview.

There are no surprises here, the only difference is that instead of visualizing the table with SP we do it by Items, exactly the same table structure but the main input is different.

In order to complement the tables, there are some charts that could help to understand better what is going on.

Here is where we see how many people we had available working in every sprint, as I said, there is not blame intention at all here, or aim to control, this will just help us to see for example, why in one sprint compared to other the SP goal was much smaller, like in Chrismas, where we have most of the people on holidays.

 

For Story Points

Here is where see for every sprint the difference of what we did and what we planned and the confidence feeling(the value is the velocity per dev day), this will help us to see for example if over and over we are all always too confident about what we can do and also to see the difference of what we did and what we planned increasing, maybe a reminder for everyone to be more realistic?

 

For Items

The same as above, but this time with Items.

 

Now my favorite, for SP and Items we have the difference in % of what we did and what we planned right? so this chart is the comparison of both values, except for the first sprint, we can easily see how the team have been always closer to what they thought they could do in terms of Items and not SP.

I know this data only belong to 6 Sprints, but currently with the data we have, if you are a PO you would trust more your team about the number of tasks they think theey can do and not the SP, even if it sounds common sense, again, “common sense is not that common”

We can see with real data that sprint over sprint is a fact that the team can predict better the number of tasks they think they can do.

With the time and experience as Scrum Master and Developer, I have seen also that the teams are in general more confident when thinking in how much they think they can do in terms of tasks.

Conclusion

Of course, I’m not saying you should not have the velocity, or you should not estimate, velocity is, of course useful if you use it in the right way and you have some stability in your team, and I also like estimations, but don’t get me wrong, what I like about estimating is not the actually SP that comes from it, is the conversation that the estimation creates among the team, it helps a lot to reduce uncertainty and give clarity.

I just wanted to share my findings, and then is up to each of us to think in what this means for us, also to continue customizing what we want to visualize for the good of the team(everyone! developers, business, customers), it helps a lot to visualize this information because I think makes the people involved to be more aware of what is going on and how are we doing. If you want to know more about it maybe you are interested in reading Patterns for a useful KPI

 

I hope you like it! and if you want the link to get access to the sample I used, just leave a comment!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.