Measuring Success – Projecting
We ended last year with of an average of 40 completed points per iteration. It’s much less than what I thought we were going to have and I’m still a little on the fence as to what exactly causes the gap between our planned and actual points, and it’s likely more than one cause (more on that in my Agile updates), for the purposes of this post I wanted to wrap up my thoughts on what specifically we were using as measurements when determining the success of a project and what for we needed to you make that are projections going forward.
So from measuring success perspective we have our planned points vs. actual points, we also have planned tasks vs. actual tasks completed, we have number of bugs (which are so rare we don’t even track them), we have unplanned tasks, and we have production releases. Most of those speak to how well we’re able to hold to commitments. Knowing the number of bugs and production releases really speaks more to quality, which isn’t an issue for us at all so I’ll leave both for a later discussion.
Looking forward, I’m feeling relatively confident that I can use 40 points as our maximum velocity for planning purposes. There are a few things to consider when looking at our projects for the year and those all play into our common estimating issues: support workload – our least successful iteration was also had the highest number of unplanned tasks, buffer – planning for absences and illness, and also solid risk management – iterations 6-9 had major issues with a server we were supplied that wasn’t set up properly and required a significant amount of testing from my team to resolve the issues. We shouldn’t have started that project (or at least rescored it) until the server was ready.
Taking all of those things into consideration means I need to tweak a few things in my project planning process and I also need to bring the team into the discussion of how we assign story points and what they represent during our next planning meeting.