I recently wrapped up a small development project where our client engaged us to design and build a customized claims administration application.
It was a high priority tactical solution driven by legal and accounting requirements that kick-started a claims process that was rolling out in three weeks. The custom claims administration application needed to be delivered within this three week timeframe to administer the process. It was high risk since the application needed to be accurate, stable and responsive since claim administers interacted with it in real-time while conversing with claimants.
In order to deliver against this aggressive timeline we needed the following:
- lightweight process that could respond to rapid changes (requirements definition was in-scope)
- a process that was easy to track progress against the goal
- a process that enabled frequent and reliable estimation for planning (we needed to know right away if we were falling behind)
- a process that would allow us to communicate to management and stakeholders on our progress and get their buy-in when we push back on features to control scope (it's amazing sometimes how non-technical resources underestimate effort, and how difficult it is to communicate realistic effort)
We rolled out a flyweight agile process driven by user stories and 1 week iterations. This would allow us to:
- prioritize stories with management and stakeholders
- estimate each user story (we used ideal days)
- create a release plan and iteration plan based on user stories (functionality and value instead of tasks)
Our first goal was to prioritize the absolutely must have user stories which would make up the first release. This release consisted of three rapid iterations targeted to launch on the three week deadline. Lower priority user stories would be rolled out in a subsequent release. Our release and estimation plan was updated weekly which allowed us to easily track and communicate progress. We also tracked our velocity and noticed after two iterations we needed another resource to meet our plan. It also allowed us to re-prioritize weekly and we evolved our release plan to break out user stories into two staggered release.
User stories were great since they were low ceremony, light on documentation and less susceptible to change since details are captured at the last moment via conversations. It really enabled agility since we were not afraid to throw away or change requirements since we placed so little investment into them (high value for low cost).
As a result we delivered on time and the project was a success.
Overall, I think an agile based approach enabled our success. Rapid feedback, frequent communication, and lightweight artifacts allowed us to respond to change and adapt to succeed.