This is an excellent way of making progress visible, depending on how many story points you burn per sprint, you can see when all stories could eventually be finished. Measuring work this way also helps business see what is the impact of them changing their minds by adding or reducing scope.
It also helps in giving a comparison between sprints, knowing if you're improving or, inversely, reducing your velocity, thus allowing the scrum master to take proper action.
But in every project there is a very important variable, budget. So, how you convert story points into budget needed for your project, or better, can you?
One can easily fall in the simpleness of trying to convert story points into man-days, sort of extracting a story points to man-days ratio and then dividing or multiplying accordingly. If you do so, you're are taking the first step of making scrum fail in your company.
But, why? Why converting story points to man-days is not an advisable thing to do?
Let me show you what happened when trying to do so.
I'm taking the role of a scrum master for a sub-team of 11 people, they take care of several applications in the company, and we usually do several projects for these applications.
When I took over the team, a whole bunch of stories were already estimated, I didn't see anything unusual about it, story points here and there, usual scrum stuff.
After a certain period our boss asked us to calculate how much a story point equated to a man-day of work, he wanted everything to be in story points, even what we communicated to the outside world would be in story points, but yet he needed to be able to "budgetize" projects.
Getting the figure he request was an easy thing to do, take the time that was actually worked in a sprint by everyone, and divide the story points delivered by this number. We delivered in average 40 story points, and worked around 80MD in total counting myself. For simplicity, let me say we had a number roughly around 0.5, thus, 1 man-day of work was equated to 0.5 story points.
This seemed quite fair. All the 3 teams within our area seemed to be around this figure too.
A couple of days ago, we had to do a high level estimate for a new project, I let the tech lead do it along with the analyst, the project itself was a very easy thing, change a couple of labels here and there in a small application.
Guess what was my surprise when my boss asked us to re-estimate as it was not possible that the change could take as much as 4 man-days when it should probably be done in 1 day of work!
We had a quick meeting to see why that was estimated like that, where the tech lead explained that the two stories were 1 story point each, so that in total the estimation was 2 story points. Nothing unusual there, 2 story points, seemed fine. After all the two stories were the same size and story points indicate relative size from one story to another.
What gave the 4 days size, was the lead analyst of the team, thus the guy that has to present estimations to business and project managers, taking our SP/MD ratio of 0.5 to divide the story points given by the tech lead. The magic "4 days of work" materialized.
When the tech lead was told that 4 man days was too much, not only did he agree upon that, but he was surprised to see that 4 days was the estimate when he just gave 2 story points. I started asking myself why there was this difference, as everyone seemed to agree on the actual working size of the project.
The tech lead then told me something that surprised me, in his mind, 2 story points was the equivalent of 1 man-day of work, and not only that, every single story that was estimated within the team was based on this ratio!
But wait! after 10 sprints, the average ratio was really 0,5, not 2, that's 4 times the actual effort!
If the team was delivering 40 story points per sprint, I should have seen an actual booking of 20 man-days, not 80 !!
Does this infer that I have a team of lazy people that actually work four times slower than they should? No, I strongly believe this is not the case, I've seen the guys working hard to deliver what was committed.
Does this mean that the guys could not estimate properly? No, not at all, estimations were done properly in story points, and surprisingly, the first project was done even ahead of schedule!
So, what went wrong?
Tying man-days to story points, that's what went wrong.
Stories are to be estimated relative to each other. Not to a fixed number. And stories should never be compared to stories of other projects, they must be compared against stories of the same project.
Independently of the way you "size" stories, you know that for each project you have a deadline, so the only thing that helps you know if you are going to reach the deadline is to calculate you team's velocity, and that you burn 300 or 1 story points per sprint do not make up to anything if you do not take into account the total size of the project. Burning 1 story point of a 1000 MD project with a total size of 500 story points is not at all the same as burning 1 story point of a 10 MD project with a total size of 10 story points.
There is a common notion that I tend to disagree with: You cannot compare from project to project, as conditions are never the same, and any previous speed is no indication of the speed you might be able to achieve in future projects.
To go back the main subject, money; how do you estimate your projects then?
- Keep the man-days estimations for the world outside your team.
- Keep the story points estimations for your team and only your team.
- Do not try to find a baseline story for all projects done by your team, but a baseline story for each project.
I'm a strong believer than neglecting to do so is paving the path for the failure of scrum in your company.
No comments:
Post a Comment