As at the point described in my last post, we had created a pile of story cards, representing a Prioritised Requirements List (PRL). Each story had associated with it relative benefit to the business, a story-point estimate of relative size and complexity, and a MoSCoW-scale prioritisation, a DSDM concept.
Now, how are we going to deliver solutions to these requirements, and just as importantly, when?
Our first task was to group all of the user stories into ‘Themes’ of related requirements. This is so that we can decide what functionality can be released into Production together. In our case, requirements or features of particular parts of the site were grouped into Themes. Those stories referring to features of the new Home page went in Theme 1, those related to up-sell and Claims (did I mention we are an Insurance company) went in Theme 2, and those related to Amendments went in Theme 3. Generally speaking, Theme 1 should be the most important and deliver the biggest benefit, but in our case, although it does deliver business benefit in its own right, it is more an enabler for Theme 2, when the big benefit is realised.
Themes are also known as Increments or Releases. I am inclined to use the term Themes when referring to user stories with the Business, and Increments when talking to the technical guys, but the terms are largely interchangeable.
From what I have read so far, all Agile methods (XP, or eXtreme Programming, Scrum, DSDM, etc.) have in common the concept of working in short periods of time called timeboxes or iterations. DSDM calls them timeboxes, so I will adhere to that term here. Each Increment comprises a number of timeboxes, so that a theme develops incrementally over a number of timeboxes until it is in a cohesive state, when it can be delivered to Production.
Within each timebox, a sub-set of requirements (stories) is analysed in detail, the solution is designed, developed and tested, and preferably deployed. DSDM differs from the others in that it allows for the probability that work will take longer than estimated but allows for contingency in the form of additional, lower-priority user stories (Could Have’s).
What we are trying to establish at this early stage is “how big is this project, and when can we deliver it?”
To get the answer to this question, it is necessary to translate the story points into a measure of duration. This brings to the fore the slippery subject of estimating. To estimate the effort involved in delivering all of the stories listed (we had over 50 of them) would have taken virtually an entire day. We therefore adopted the idea of estimating only the stories in Theme 1. This would give us a reasonably accurate estimate (with a 70% confidence) of a delivery date for that Theme or Increment. I then took the total story point count for Theme 1, and divided it into the total effort estimated to give a ratio, that I then applied to the total story point count for the stories in the other Increments.
I then played around with some figures in Excel (as managers are wont to do), to try to work out the best duration for each timebox. Generally it is better to have short timeboxes than long ones, and for completely the wrong reasons (don’t even go there), I settled on a standard duration of ten working days.
Knowing how long each timebox would last, how many people were assigned to the project (three, plus a part-time tech lead), and the estimated effort required, I could easily calculate that we would need 11 timeboxes to deliver the entire project.
Right, that’s the high-level planning done. Now for the detail.
No comments:
Post a Comment