This week, one of the questions I’ve been asking myself is whether we should have one estimate per story (or product backlog item) or more than one.
Our development team is new, and – at least in the beginning – not cross functional. The main split is between developers and testers. So I’ve been considering having two estimates: one for development and one for test.
The advantage of doing this is that, I think, it would allow us to arrange the work in Sprints more easily, especially in the longer term. It makes it more visible that certain combinations of user stories just won’t fit in one sprint, even if the total story points are less than whatever our velocity is.
However, the more I think about it, the more it doesn’t seem such a great idea.
Firstly – Scrum teams are supposed to be, if not fully cross-functional, at least semi cross-functional. If we start off with two estimates, how long before we end up needing another separate one for our UI designers, and eventually one for each team member … I’m hoping that having one estimate will help us remember that we should be striving to be more cross-functional and self-managed.
Secondly, even having two estimates isn’t going to give us a perfectly clear idea of what we can and can’t do within one Sprint. At least in the first Sprints there are going to be tasks that can only be done by one person. So ultimately, it’s probably even more confusing.
I’ve found it difficult to find much discussion around this subject. I’m reading Mike Cohn’s book Agile Estimating and Planning, and he advocates using one estimate except in extreme circumstances. I haven’t found much yet to help me address our situation though.
My proposed solution is to have one estimate and use the Sprint Planning meeting to facilitate discussions of what stories we can and can’t do. One technique I learned on the ScrumMaster course was to have the team work through the highest priority stories, or backlog items, one at a time, breaking each into tasks, and stop when we think we can’t do any more.
Taking this one step further, if the team estimate and accept the tasks as we break down the stories, it should become clear when certain team members are “full”. It’ll be interesting to try this and see if it works, particularly how we can rearrange tasks and choose extra stories to fill up the time of the other team members. As with everything else I’m going to try it and see … watch this space for updates.