The Living Room Architect talks about a Story Matrix, as a way of facilitating a smoother flow for estimating a bunch of stories. Good idea.
One problem still persists though, is the formality of it, with the whole points debate: do we use Fibonacci, linear, exponential, what? What do the numbers mean? And the apprehention on the part of us developers to be specific with stories they have only just begun to think about.
Someone today introduced me to T-shirt Sized Estimation - you basically cluster your stories into S, M and L. Sizes cover plain "lines of code", complexity and risk. But it has an implied light touch which seems to solve some problems I think, it seemed to go quickly and easily, and we did get a result out of it.
- No numbers, so nothing to get too hung up about
- Only 3 categories, so we don't have to discuss things for very long - it is implied that this isn't the final clustering
- We still got to communicate about the stories, so Agile Tick Mark™ right there
- And we got a rough set of estimates
Now, that isn't of course the final word in the estimation process, and we all know that, so no point in getting defensive. We will need numbers at some point. But it got us perhaps half way. We did talk about our understanding of the stories, and we did get a picture of how hard the project might be.
But most importantly, we didn't get hung up on details - instead we split the process into 2 (or more) phases. A bit like when you look at algorithms, you know that when you need to traverse a graph and do something complicated, you can either write the mother of all recursive functions, or you can split up into separate stages (search and modify stages for example). In the end, we all know that O(n) + O(n) = O(n) - i.e. the amount of effort will be the same, but it will be easier to manage the two things separately.
We will certainly need another card session, and we will need some numbers at some point, but for now we have fleshed out some things, in a very short time and noone has run off crying. And that has to be considered progress.
2 comments:
Nice,
I agree that the more we can do to eliminate wasted time in planning sessions the better. I believe that you can reach a point very quickly where it doesn't matter how much more planning you do it won't get any more accurate.
Estimates of software tasks are never going to be accurate. So it's important that a team finds a method they are happy with, does it quickly and moves on. That way you get to actually writing the code more quickly and that's when the real learning about how long a project is going to take really starts.
I'd say the purpose isn't necessarily to go away and write code, but certainly go away with more of a shared understanding that can direct more reading, spiking, coding etc.
This rough estimation forces everyone to think about and discuss things in some detail, whereas if you go straight into the big and final estimation session, everyone will be starting from scratch and it will be painful and unproductive.
Post a Comment