By Nick Butler
Tags: Agile , Development
This case study on reducing risk with Agile prioritisation is part of my ongoing series on project risk management with Agile. It follows on from my post on using Agile prioritisation to reduce software development risk.
You’ll learn how rigorous prioritisation let us release our product earlier and use the feedback and revenue this generated to build a product that best met the needs of our customers.
To see how reducing risk with Agile prioritisation can produce better products faster, we’re looking at a first-impression user-testing service called IntuitionHQ. Back in 2011, Boost produced the IntuitionHQ iPad application to support the award-winning IntuitionHQ software as a service application.
The goal of this project was to get a product to market as quickly as possible. We wanted to capture the application name ‘usability’ in the App Store and be the first native usability testing application on iOS devices. IntuitionHQ wasn’t our core business so it wasn’t something we wanted to invest a great deal of time on.
Our first step was to run a user story mapping workshop to gather requirements. In this workshop, we gathered a large number of potential features. We prioritised them on the basis of value to users and drew an arbitrary line at what we perceived to be the smallest amount of functionality that would offer value to users (the minimum viable product or MVP).
Although the team had an idea of the minimum features needed for the app to be valuable, the backlog of these features was still strictly prioritised so that the team was always working on the feature that, at the time, offered the most value.
We inspected the output of the team regularly, and once two-thirds of the MVP was completed, the product offered enough value to users to be released.
It was something of an ‘ah-ha moment’ for us. We had been working for a number of weeks on the product. Right from the start we had the app running on the iPad. In the very first iteration all you could do was log in; after the second iteration you could log in and see a list of projects; and then by the third, you could log in, see a list of projects, choose a project and collect clicks. So the app started to build, bit by bit.
One day I was sitting at my desk and Mike (our designer) came over. He said “Hey, have a look at this. I think it’s enough to launch!”. We sat down and went through the functionality. It was definitely minimal, and it was good. We agreed that as the app was now, we could use it and it would be valuable. We stopped work on the story that was in progress, wrote a number of new stories around submission to the App store, prioritised those and started a new sprint (Scrum iteration). Two weeks later we were in the App Store.
The product immediately started generating revenue, which in turn supported further development.
By working on the highest priority features, we reduced the risk of cost overruns. The product started generating a return on investment 30% earlier than we had anticipated.
An additional benefit of getting to the MVP earlier was that the team now had the capacity to take the app through the App Store submission process, something we hadn’t done before. This uncovered unanticipated delays with the submission process. The team took the opportunity to continue to add functionality which was released as an update soon after the app’s initial release.
Once the application was in customers’ hands, we started to receive additional feedback on the features that were useful, what users would like to see in future versions and a small number of defects.
We were able to address the defects within the resource originally allocated to the project. We then re-prioritised new features based on the feedback we were receiving from our users, increasing the value of the application.
It was only by strictly prioritising the work that we were able to achieve this. Otherwise we would have spent time and energy on features that were not critical and taken longer to build the minimally viable features of our product.
If you have limited time and resource, focus on your top priorities to get the highest value quickly. You may be surprised how few features you need to release for your product to be valuable.
| Guidance | Case studies & resources |
|---|---|
| Introduction to project risk management with Agile | Agile risk management checklist — check and tune your practice |
| Effective prioritisation | |
| Reduce software development risk with Agile prioritisation | Reducing risk with Agile prioritisation: IntuitionHQ case study |
| Increasing transparency | |
| How Agile transparency reduces project risk | Risk transparency: Smells, Meteors & Upgrades Board case study |
| Limiting work in progress | |
| Manage project risk by limiting work in progress | Reducing WIP to limit risk: Blocked stories case study |
| Reducing batch size | |
| How to reduce batch size in Agile software development | Reducing batch size to manage risk: Story splitting case study |
