PM/PO, here is how you can have some deliver predictability with basic statistic applying in the team throughput
TL:DR; How can we have the predictability of team deliver? Using some basic statistic, we can extract some good pieces of information from team Throughput, answering questions like: with 75% of certain, how many tasks the team delivers in a week? To do so, we use MODE, MEDIAN and PERCENTILE measures.
Answers that all PM/PO would like to know
Like a Product Manager/Owner, is an important thing to know how the team is performing. This is good to know to understand how faster the roadmap and the backlog will be delivered. Another good thing is getting some predictability of delivery. Here I tried to show how we can, together with Agile Coach, bring some numbers to the light.
In a software development environment, Throughput is the number of delivered tasks in a specific period of time. This time period is defined by the team, however, usually, we measure the number of tasks delivered within a week.
Generally, the Throughput data is used to calculate only the average weekly deliveries of the team. I want you to try to think a little further by trying to use that data to give you more interesting information about your team’s performance.
The real thing here is to get more and more predictability. We can do that getting some easy information like:
- It is common that our team deliver # tasks per week.
- We have 50% of certain that we can deliver # tasks in a week
- In 25% of the time, the team delivers # tasks per week or less.
- In 75% of the time, the team delivers # tasks per week or more.
- What is the minimum amount delivered in a week?
- What is the maximum amount delivered in a week?
Grabbing some data from the kanban/scrum board, we can apply some basic statistic to get this information and use to give more predictability to the stakeholders and the team.
With this numbers, we can get graphs like this:
Disclaimers:
Throughput is not Velocity
While the first one marks the number of tasks done over a period of time, the second is based on the unit that the team chose to define the size of a task, so there are two very different metrics.
One important thing: Throughput is only fully trusted if the tasks are of similar sizes. I prefer to break down the tasks in the smallest possible size so that they remain functional increments. So we do not usually define story points or anything like that for the tasks, as our goal is to make the tasks that we only can deliver in a week.
Task Delivery Day
Don’t matters which methodology or management framework you are using, to measure the Throughput you need will need to know the day that the task was delivered. Don’t matter the tool you are using: jira, trello or spreadsheet, you need to know the day that the task was concluded. Without that, we can do nothing.
This is the only data you need right now. From it, we will discover other data to give us all the answers we need.
Spreadsheet
Today I use the Jira to manage the tasks and backlog. The Jira have some graphs and numbers, but, to have more control and trusted numbers, I prefer to use a spreadsheet to get some numbers. So, I export from Jira the team task list, with two pieces of information: delivery date and the task name.
After that, I put all these information into a spreadsheet and extract the information that I want.
First of all, discovering the week number
To know how many tasks the team delivered in the weeks of the year, we need to sum all tasks delivered in the weeks. Duh. :-)
This is easy: Since you have the date of delivery, you will discover the week number of the task. To this article, I’m using the Google Spreadsheet. There has a function called =weeknum(), which gives me the week number of a specific date.
Now that we know the number of each week, we can discover the Throughput: the number of tasks delivered of each week of the year. To do that, we create another table with a column showing the week number and another column with the sum of tasks delivered in that week.
We do that using the CountIf formula: =countif(interval, criteria):
This information is already important enough for some people: you’ve just figured out how many tasks were delivered each week. You can already do a basic report for the bosses. Let’s now try to answer the questions at the beginning of the article (the answers that the Jira will not give to you).
Which the minimum and the maximum number of tasks delivered in a week?
This information is good for knowing the forecast of pessimistic and optimistic delivery.
Several reasons can make software development a complex environment: unforeseen bugs in production, unstable infrastructure, developer vacations, lack of testing, unforeseen requests for urgent tasks and so on. All of this can influence to bad the weekly deliveries of the team.
On the other hand, there are weeks when many tasks have been delivered. This is not necessarily good, since the team may have come out of a bad week, where tasks were stalled until problems were solved. Or, if there were no problems, the high deliveries may have been a result of the high productivity of the team … which is great news.
To find out which week you delivered fewer or more tasks, we will use two measures of dispersion: minimum and maximum.
Know, with these numbers, we can respond:
Our team can deliver a minimum of 4 tasks in a week. So, this information is good to know when we are planning tasks to a sprint. We know that if we put 3 tasks, we have a good chance to complete all tasks. But, usually, the minimum number can be very low, like 0 or 1.
Is COMMON to our team deliver # tasks a week
What if we confirm that it is very common that our team delivers 6, 7, or 10 tasks per week?
Over time, the team begins to identify a cadence, delivering more or less the same number of tasks. With the measure of a central trend called MODE, we can know what is the most common delivery quantity of the team.
The MODE discovers the number that appears most often in a data distribution.
This is a good answer for anyone that can understand the performance of the team. In this example, we have two weeks that the team deliver 6 tasks. In a big distribution, this is very util to know that this number appears more than any other number. This is good, but not so good, because 6 can appear more than any other number, but other numbers still the majority. That is, by comparing the quantity that 6 appears with the quantity that other numbers appear, the chance of the team are delivering more or less than 6 is still great.
Here, we gain a little more predictability. But, we can go further to get more predictability.
We have 50% of certain that we can deliver # tasks in a week
Use the AVERAGE to get some predictability is bad for a team that doesn’t have a cadence. The numbers that are outliers can manipulate the average number and you will base your predictability in the wrong number. In truth, the lack of cadence is a problem to get any number. But, if the team have some cadence and don’t have discrepancies in your deliveries, you can use the MEDIAN measure to get 50% of certain.
With the MEDIAN number, we can say that our team delivers 6 tasks (or more) in 50% of times.
The minimum number of tasks we can deliver is 4. But we have 50% of certain that we can deliver 6,5 tasks. So, we can have some pessimistic predictability that we can deliver something between 4 and 6,5 tasks in the next weeks.
This certainty becomes more accurate as time passes and we insert more data into the worksheet. More date is more knowledge about the team.
Can we get more predictability? We can say that in 80% of times we deliver # tasks in a week? Yes, we can!
Using percentile to get some predictability answers
Now, to know how many tasks the team delivers in 25%, 60%, 80% of the time, we use the percentile measure. The percentile divide in 100 parts the data distribution, each part with a percentage of data approximately equal.
In our example, the Percentile 50%, indicates that the team delivers 6 tasks or less in a week (median).
Now, changing the 50% to 75%, we can say that in 75% of the time, the team delivers 7,8 tasks os less in a week. Another view of that number is that in just 25% of the time, that team can deliver more than 7,8 tasks in a week.
We can change the percentage to get an optimistic vision of team delivers…
The approach used to analyze throughput can also be used to analyze leadtime, that is, the amount of time the team takes to deliver only one task.
Conclusion
In my humble opinion, these metrics are far more useful than just knowing the average deliveries. This makes the product development process more empirical, giving more information to all interested people.
This also begins to basically approach, the #NoEstimates concept, which encourages the idea of dealing with projects and products without the estimation phase, whether it is point estimates or any other unit.
It is latent then that the use of historical data to predict the delivery of a project by a given team is a more acceptable practice since we take into account a series of normal behaviours of the environment and the team. Even if we do not use any ordinary estimation technique at all, we take a very initial step,
where it is possible to know the frequency of delivery of the team, bringing more confidence in how many tasks they can deliver in the coming weeks since the stories have similar sizes.
If you want to see the spreadsheet used in this article, follow the link: https://docs.google.com/spreadsheets/d/1Fd1Jfb9miULim__ef1RDBqXyJo01qwfXb7r0mJXCCfk/edit?usp=sharing
