Three seemingly independent occurrences happened to me recently:
- A couple of weeks ago I had the privilege to read an upcoming book about #NoEstimates by Vasco Duarte.
- A couple of days ago I read a very interesting blog post called ”How far have we come?” by Marcus Hammarberg.
- My boss recently assigned me with the following task: ”Can you make a status report where we are in the project?”
I thought for a while, can I connect these things? There must be a way to solve my immediate task by using what I’ve learnt recently. This is what I came up with.
Poor man’s project forecasting
Some time ago I asked the team to start measuring how many stickies they complete peer week. I got this idea from the book ”Kanban in Action” that you really need to buy! If you wonder why you should do that, I’ve done a review of it. The reason we started up this measuring was to see if our kaizen efforts (continuous improvements) was positive or negative.
Every Friday the team leader counts all the stickies that are in the ”Done” column on the Kanban board, write the figure on the board, and then remove them. This is repeated every Friday. Each sticky correspond in our kanban to a bug fix or a sub-task of a story/feature. Hence, the measuring is done on the lowest level of work that we track, and not on the story- or feature-level (that is suggested in the book by Vasco Duarte).
By plotting the numbers stored for each week the picture above was created. In the spread sheet program I’m using it was also possible to calculate an average, in this case 18 tasks/week.
You can argue that some of those tasks were one hour of work, while others may have been taking a much longer time to complete (days or even weeks). That is true of course, but by measuring over a longer period of time, these things ”evens out”.
One more argument against this kind of measurement is that work in progress is not considered or valued. Ongoing tasks are not considered, for example a task that was originally estimated to five days, and now only have one day left on it, i.e. should be 80% done. My answer to that is, how do you know that it’s 20% left? That is just an estimate. You don’t know that it’s done, before it’s done! 🙂
Remember that the effort for performing this measurement is less than five minutes per week!
Actions possible thanks to forecasting
Someone once did a time plan stating that the project needed 6 weeks for bug fixing. I have to admit, it was me, back in my ”old life”. 🙂
Looking inside our bug tracking system, I found that 213 bugs were assigned to the project. Huh, do you just like me hate to manage long lists in bug tracking systems or spread sheets? Maybe you can make use of the priority pyramid.
Now it was time fire up my favorite calculator:
- Actual time to solve all bugs = 213 / 18 = 12 weeks (double the planned time)
- Number of possible bugs to solve within the given time plan = 6 * 18 = 108 (roughly half the scope)
Consulting The Iron Triangle we could come to the following conclusions:
- Cost – Investigate the possibility to borrow some members from another team to help out with this project
- Time – Investigate the possibility to delay the project delivery with the steering group
- Scope – Initiate activities to manage the scope. Must this bug be solved in this project, or can it wait? Is it old and can be removed? Is this bug already fixed, but our tracking system has not been updated? And so on.
Wait a minute, couldn’t you have come to the same conclusions without forecasting? Well, we probably could in some way. We know that the project was ”running late” (that’s why the status report activity was initiated). Based on our so called ”gut feeling” we could have reached similar conclusions. However, I rather base my decisions on actual data that my brain can analyze, than ”feelings” from my stomach. 🙂
Was it hard to do this? No. Was it useful? Yes. We took a meeting to discuss the outcome, and immediate actions could be taken. This way of doing poor man’s project forecasting will be in my toolbox from now on!
Finally, #NoEstimates is now so established that jokes about it are popping up. This is one of them, enjoy!
All the best,
Tomas from TheAgileist