Dear Product Owner, Scrum Master, Stakeholder or anyone else who needs to know when their project/release is finished,
in any project or product development there is a need of being able to know when your fancy new product is ready to go live or when your piece of work can be integrated with the rest.
There are many good reasons why you want to know when you’ll be done.
As we all know in traditional waterfall projects you always know when you will go live, sometimes years ahead, UNTIL the hidden monster of variability shows up and kills the deadline several times. Sometimes up to the extent where the whole thing gets cancelled.
In this blog-post I show you a different approach on how to keep progress transparent to ensure you can keep your deadline.
Variability kills Deadlines – and Projects
Ok so here I go, being Scrum Master of a fresh one year project and we got a new Product Owner that never worked with Scrum before and had a Waterfall career for 15-20 years.
We started the project and after 3-4 months senior management steps in to ask “where are we standing with the project, will we deliver on time within budget?”.
And the PO tells them he doesn’t know. So senior management tells him to create the full backlog of things that have to be done for the project and estimate them with the team. But better use only one or maybe two persons of the team, because that’s cheaper. 😉
So the guy goes off for 2 weeks and starts writing Stories after stories until there are 180-200 stories in the backlog. And he hands that over to 2 developers to estimate the whole lot of stories.
So after 2-3 days of going through all that stories and estimating them those guys come up with a whooping 1000 Story Points to be delivered.
So the PO came to me and said, tell me when we will be ready. And I told him “I don’t know”.
“You have a completely fresh team of people that never worked together before, it takes at least 2-3 sprints to settle the team and get an idea about their velocity. And even then this velocity is a very bad indicator to tell you if you will be done in time or not. There is a lot of work yet undiscovered that will completely ruin what you will create now as a graph trying to predict the future.
The guy continued his journey 1-2 more months until the team asked me to step out of my Scrum Master role and into the Product Owner role.
You can never accurately estimate what you yet don’t know
So my first course of action was to throw away the old backlog and together with the customer discuss on a feature/epic level what they urgently need and what can be left out.
On this rough level I asked them to order the features in terms of importance and value.
From there on I started to break those features down to “Vertical slices” (I’ll explain that in a future blog post). And to know where we are compared to where we want to be at the end of the project I created a Release Burn-Up.
The blue line (and y-axis) on top shows the number of work items to do (in this case stories).
The x-Axis shows the number of sprints
The orange line is the speed needed to reach the Go-Live date.
And the red line shows the number of items done so far.
As you can see the project was in deep trouble when I initially took over and created that chart.
The easy and secret ingredient to this graph is:
The count of Stories done per Sprint
Teams output can vary a lot, depending on unknowns, sickness, vacation and input.
Also stories can be quite different in size and complexity.
Here is the distribution of the stories for this 12 month project.
The average of all the 191 Stories done in all the sprints was 8,91.
The majority of all stories was 8 or 13.
Now you might wonder, why this team still had story points? #NoEstimate tells you to get rid of estimations, right? Story points were here used to tell apart big stories from properly sized ones. A story with 40 story points never made it into a sprint but was splitted in at least 2-3 smaller stories.
What you want to have for #NoEstimates is small stories that can be done in 2-3 days.
Stories done per Sprint
With average sized stories the secret of this approach starts to work.
You are able to calculate the average of stories done per sprint to use it in the forecast of when you will be done.
As you can see in the graphic below the number of items done per sprint stabilises as the team stabilised and the collaboration got better.
The full journey
Now with all this information I was able to talk about scope, deadlines and re-plan the whole thing.
As you can see in the picture below there were regular corrections on the scope as well as on the go live date. If you can tell a customer, you won’t be able to get all of the scope Sprint 16 but we can deliver it after Sprint 19 do you want to keep the Scope and get it later or de-scope and get it earlier, you can have much better informed decisions.
What is the difference between Estimating and this approach?
Let me come back to the initial story of having the initial backlog completely estimated which resulted in a total of 1000 story points for all the things to do.
- Over the course of the project many stories that were initially estimated as 20 story points literally “exploded” to 5-6 stories of 8-13 story points
- Almost none of the stories were underestimated
- A lot of stories that have been estimated were no longer needed
- 6 months later of the initially estimated 1000 story points a whooping total of 1685 story points were finished, which is a deviation of 60%, which is actually not that bad for an estimation but would have been disastrous for the Go-Live of the project
- Estimating costs time and money, in this example the initial estimated was more than one full week for one person and for it to be meaningful you would have to re-estimate after every sprint
- Estimating doesn’t deliver value, no story is delivered by it, no customer would ever pay for it
Counting done Stories is much easier and much more precise than using estimates.
And much more important: it’s based on empirical data rather than weak attempts to predict the future.
All you can do is manage Scope
What I’ve learned from all the previous products and teams that I’ve worked with is that the only reliable way to ensure that a project or product Release is on time is to actively, aggressively and well-informed manage the scope.
Please have a look at the blue scope line in the “Release Progress over time”to see how the scope changed over the course of the project.
- You can’t speed up teams by incentivising them or using the whip on them
- The more people you add to the project the later it gets
- Variability will bite you in the ass every time there is a chance for it
Before you start your next Project/Release
Think about what you already know about the work that lies ahead of you.
If it has many unknowns, but you have a stable team that worked together for some time and also a PO who knows how to slice the work you might want to start this new way of doing projects.
It will give you much clearer information and removes the hassle of doing the big specification up-front.
If you have questions on how to implement the approach feel free to add a comment or write me on Twitter @MrSnow76.
Thx for reading,
Sven Schnee aka MrSnow76