Greetings,
let us go and write down a number of fuzzy numbers which are supposed to resemble development time, risk and value, and be happy with them, until we notice how horribly wrong they are. Once we arrive there, we can decide to either run around screaming or we can re-estimate and make some manager run around screaming. Both possibilities will be fun somehow.
In case you are wondering why I am posting at this rapid speed: Currently, I have to share a computer with several other people, so I have a certain backlog of content piled up at the moment, and if I say “I will estimate things now”, I pretty much meant “Yesterday evening, I formulated the post in my head, and yesterday evening, I figured I will estimate now.”, and thus, the estimation is about done right now.
At first, I had to estimate the stories in 1, 2 or 3 weeks of Ideal Development time. This was the regular estimation problem, so I basically went through the stories, assigned a single week to them (and for some of the stories, a single week feels like an awful lot of time, but I think the project velocity should be able to fix this) and assigned 2 or 3 weeks of time to just a very small number of the stories (In numbers: of 77 stories, 62 have been estimated 1 week, 12 have been estimated 2 weeks and 3 have been estimated 3 weeks). However, I think this distribution makes sense, as my application is mostly a simple web frontend for a database which pushes data around in the database, so most of the tasks are simple forms feeding queries to the database and displaying the results. Those 2 week stories are mostly the version control stories and the 3 week stories are stories involving technology I am unsure about (recovering passwords, as this involves the use of emails, and I am not sure how I will test this) and one of the version control stories (recovering a deleted hint-through).
Second, I had to assign buissness value to my stories. I was not entirely satisfied with just assigning low, medium and high to the stories, because for example, the community part felt more important than the version control for hint throughs, but less important than actually developing the hint-throughs, but the version control part felt more important than the rating mechanism for comments. Thus, I tricked myself by allowing myself to assign buissness values on a scale from 5 to 0. 5 means “Critical: If we do not implement this, the system is just worthless”, while 0 means “Well, if we are eventually done, we can implement this, but if this is missing, it is not so bad.”. In the planning game, I can then merge values 5 and 4 into high buisness value, 3 and 2 into medium buisness value and 1 and 1 into low buisness value. If I am unsure which high-value stories I want to pick, I can still pick those with a value of 5 over those with a value of 4, of course. Most of the stories are rated 4 to 3, which again makes sense to me. In numbers, of 77 stories 17 stories are rated 5 (Basic hint-through development stories and basic account management stories), 22 are rated 4 (Administrative stories, basic forum functionalities, searching for hint-throughs, basic messages), 31 are rated 3 (Flagging, Markup, version control, additional features for the high-value components), 6 are rated 2 (comment versions, additional content for user pages, recovering deleted hint-throughs (hey, accidentially deleting a hint-through really requires a lot of work, so it won’t happen often, I hope)) and the remaining 2 stories are rated value 1 (rating comments). I think this heavy bias to high- and very high buisness value stories makes sense, because I wrote down user stories for the core system I envisioned, and thus, most of the functionality I want to develop is pretty critical for the system.
After that, I had to assess risk. I planned to estimate risk in three categories and combine them into an overall risk value. The first category is completeness of the description, or “Do I know everything?”. If I am confident that I know everything I need to know, I rate the completeness-risk low, if the story is very vague, the completeness-risk is high, otherwise, it is somewhere in the middle. The second category is implementation complexity. If I look at a story, I check if I can easily think of a way to implement this, or if I already see some tricky problems popping up (e.g. the version control will be pretty tricky to implement, while adding a comment is fairly simple). If the complexity then directly translates into the risk of this category. The third category I looked at was volatility, as in “How often will this change?”. If it changes often, the risk is high, if it changes like a mountain, the risk is low. Given these three thoughts, one can easily combine the risk into an overall risk. If everything is low for example, the overall risk is probably low. If the risk is medium in two of the categories, the overall risk probably is in the upper area of middle, too. If I was unsure about a certain risk, I usually picked the higher category. Given this, of 77 stories, 1 story was rated high risk (Recovering delete hint-throughs, because this felt pretty complicated to implement and I was not entirely sure about how long a hint-through is kept), 10 were rated medium (posts, version control, searching, recovering passwords) and the remaining 66 stories are rated low risk. I think this makes sense, because I have a pretty clear vision of the application I want to create and thus, the risk of incompleteness is pretty low. Second, most of these mechanics are pretty basic and thus, most of the mechanisms cannot change much (at most, they can move from one page to another), so the volatility risk is pretty low, too. There are just a few stories in there which feel tricky to implement (recovering delete hint-throughs, version control, polls), so they are rated with medium or even high risk. But again, the bulk of the stories (adding comments, adding notes to hint-throughs, account management) are mostly database operations with form in front of them, and thus, pretty easy.
Thus, overall, I think the estimation, value and risk estimation resulted in a sort of sensible result and I can walk into a scope based release planning now (where I probably will pick all the value 5 stories and call it a release).
Regards,
Tetha.
