We all know the feeling. You sit down in a Sprint Planning meeting and a project manager walks in. The instant that he sits down you can tell there will be some tension. He wants to do it. He is compelled to. He will absolutely try to force real world hours on your estimations. He lives in a world of black and white and the only justification of the work that you are doing is measured in time. He will take your Story Points, and turn them into something they are not. Time. If you can empathize with the story above, you are not alone. This blog post will talk about tackling the ideology change I believe is needed to ensure accurate estimations.
How Project Managers Sometimes View Agile
We have all seen it, and there are countless stories out there that talk of the same thing. There seems to be a rift between what Agile wants us to do and how traditional project management looks at the idea of planning. To project managers, planning is how much time you have. Specifically, in our case, planning our developer resources. If you have 50 hours’ worth of work time for your dev team, you should be able to break down all your development tasks into hour estimations and map them back 1 to 1. This would allow you to see how much work should/could be done in the sprint. There is a fundamental issue with this approach and a solution that AGILE tries to give us.
Here’s a little example of what I mean:
- When is the last time you were able to work every minute of every second that you were in the office?
- When is the last time Chuck from the QA team came to ask you about an item he found strange while you were in the middle of something else?
- When is the last time a development task tested green on the first try?
These things happen daily. Development does not always go according to plan. And Chuck’s quick inquiries don’t help. He is a jerk and needs to follow the process. The point is these interruptions in planning happen, and often. Making the simple changes below can insulate you against interruptions and usher you towards more accurate estimations making success in planning possible.
Why is My Burndown Failing?
These kinds of intrusions are not accounted for in the Hours to Story Points method. There is simply no good way to account for them. You may make an adjustment to a task to account for it, but you don’t know that this small task will take much longer due to Chuck’s incompetence. Then, sometimes, Chuck does not show up at all!
When these types of fluctuations make their way into your estimation, a funny thing happens to your burndowns. These behaviors are exhibited in your burndown charts throughout the sprint. Burndowns become all sorts of other things: burn ups (the opposite of what you should see), burn overs, and my personal favorite, burn plateaus. You should ideally be following a nice trend of completion, but those unaccounted for issues pop up and either stop your downward momentum or add unforeseen tasks, thereby creating upward movement.
Adjusting Your Attitude to Fix Your Burndown
There is an alternative. There is light. We can acknowledge that the Story Point is actually an estimation of difficulty, and not time. This is a very hard idea to grasp sometimes, as switching to abstract from discreet ideas can be troublesome for some people. If you change your “Story Points” to some other unit of measure, say, “Oranges” for a few sprints you will see a difference. The reason is because you are not forced to account for the unaccountable (I am looking at you Chuck), but you embrace them.
Now, there is a significant growing pain here. The reason being you may be:
- Used to very high numbers in terms of story points in a given sprint
- Used to reporting these things upward (why!) as an indication of velocity
The first time you use the “Difficulty estimation” rather than trying to force hours onto it, you will find that the amount of “points (or oranges)” is much lower than normal. This can be jarring if someone is living their life by their burndown or velocity.
The bottom line here is that the estimation process informs your burndown. The burndown is aggregated into your velocity. These numbers are easily changed from sprint to sprint. You can easily just make it “appear” that you are doing well by making your estimation larger and still completing it. Story points are just numbers, which can be manipulated to show anything. What is more important is that your team starts to look at tasking and resources in terms of difficulty, and their ability to handle these difficulties.
Firsthand, I have seen the fruits of the change in ideology I am talking about. For months and months, sprints upon sprints, our burndown suffered. We were constantly appearing behind. We were not, in fact, behind but our estimation process was tied to time and therefore we were constantly biting off more work than we could accomplish in a sprint. Countless changes in the “formula” for calculating man hours were made, but the outcome was always the same, disaster.
Once we made the change, to using difficulty instead of time, a much clearer picture formed. One that shined light on where the true issues around given tasks were. When this occurred our burndown righted itself. We are now able to have intelligent conversations about how much work we should be looking at for any given sprint.
Learn more about how we implement Agile in our current work and explore other Agile blog posts. While you’re here, make yourself comfortable and check out our blog home page to explore other technologies we use on a daily basis and the fixes we’ve solved in our day to day work.
