I was surprisingly calm about the prospects of having to start managing projects at a new company and learn a completely new methodology as well. I had done it before, but all my previous employers used big, heavyweight frameworks high on process and bureaucracy. You don't have to think too much; you just follow the process. Like a robot. Agile is different. This company is different. This is the first in a series of posts, in which I will describe how we adopted Agile in this company, and in what aspects we deviated from the ‘textbook’ approach and why. In this first post, I will run through the initial estimating workshops.
Agile textbooks suggest that the process begins with the initial idea for the project – the users should not know too much about the requirements too soon. In this case, a fair amount of thought had already gone into what the requirements were. The product owners were given a template into which they wrote a series of bullet-point requirements, essentially user-stories. The template was broken down by stakeholder, so that we could identify Customers requirements separately from Finance or Underwriting requirements, for example.
For companies adopting an Agile approach for the first time, it is essential that you get someone who understands the approach and how to adapt it. You will need someone to help guide you along the way and suggest how to do things to achieve the best results. In our case, we have nominated Geoff, a business analyst who spent most of December learning about Agile himself as our ‘champion’. He has also been able to get some consultancy time from Andy, who works for an external company who specialises in doing this sort of thing. Together they guided us through the initial couple of workshops.
It is vitally important that as many relevant people as possible attend these workshops to maximise universal understanding of the requirements and the drivers for the project. Because the project has not yet been formally approved, we were limited by the absence of a technical team – the developers who would undertake the work. They were, however, represented by the technical architect who knew more about the system and its functionality than any other individual. We also had no DBA or hardware specialist present. Hopefully their absence will not be significant at this stage.
Geoff had transcribed the initial high-level bullet-point requirements that the product owners wrote up, onto a pile of 4” X 5” cards known as story cards. These were then ranked into High, Medium and Low according to the perceived priority. We did this purely as a way of getting into the mindset of ‘chunking’ things up, a top-down approach, and relative prioritisation.
Story Points
For each (H,M,L) pile of cards, we then estimated their size and complexity in story points. There are a few possible scales to use for this but we settled on the most common one – 0,1,2,3,5,8,13,20. It is important that all aspects of the story are recognised, especially the degree of uncertainty. If the requirement is unclear (and it frequently will be at this stage), factor in the need for additional research, analysis, usability studies, etc, as well as the usual development and testing effort.
The thing to remember about story points is that they are relative only to other stories within the project. They are not comparable across projects.
Benefit
Once the story points had been allocated, we went through the cards again to assess the relative benefit of each feature. This is where the use of cards proved invaluable. The product owner and his team simply sorted the cards in descending order of which would provide the most benefit. We then annotated the cards with BB:1 for the card that provided the greatest benefit, then BB:2 and so on.
MoSCoW
Given the size and relative benefit of each story, the product owner then felt comfortable assigning priorities to them according to the MoSCoW scale of Must have, Should have, Could have or Won’t have.
This already looked like a fairly sizeable project, and getting to this point took up two half-day sessions, but it was well worth it.
My next post will describe the next stage of the process – determining duration.
