Before the Backlog – The Vital Upfront Research
My learning journey
As a Business Analyst, I believe my purpose is to ensure the right product is being produced. Having previously created a successful renewal of a product I’ve been on a mission to understand what I did right, how it could have been even better and how the approach can be scaled. Unusually I had the opportunity to take the Cargo flights product, described below, from successfully rewriting a Business case through to customer use. I was also allowed the opportunity to introduce an Agile approach, which worked very successfully.
Agile came to prominence from the software development world, and many wrongly assume that it’s just for developers, failing to adequately take into consideration the essential customer interaction that is necessarily involved. Such thinking is probably 20 years out of date. As systems have got larger and more integrated, we need to review what’s happening upstream.
The vital, but often neglected, initial work
I’ve observed that the vast majority of Agile books only focus on what happens after the initial Backlog is produced. In Scrum, it is generally agreed that a “Vision” is required, and Scrum has created a role called ‘Product Owner’ who is expected to deliver a Product backlog. But how the Vision is achieved and how it transforms into the Product backlog is frequently not given sufficient thought. As Angela Wick says even “…teams that create a product vision, […] never use it”.
Having been presented with a list of 1,100 requirements on one project, I was already aware that the traditional approach, i.e. collecting a list of ‘Requirements’ from management, was not the appropriate way to build products. And I assisted a colleague in his PhD on Requirements wherein he demonstrated that lists don’t work for products. I considered myself more of an investigative Business Analyst so I’ve always dug deeper into the situation rather than accepting requirements at face value.
Doing the research
On the Cargo Flights product I did a lot of research to understand what users were trying to achieve; listening to prospects’ objections when they failed to buy the existing version; talking to customers at exhibitions; doing customer surveys; looking at what the competition was offering and discovering what the major customers wanted.
The major customers wanted additional ways of controlling their users’ on-screen choices. However, this did not affect the basic needs of all users. Competitors had lots of interesting features, but I considered that this did not directly address the job that the user was trying to achieve, so I didn’t bother with these fancy ideas. Out of this huge list of wants I was able to focus on the minimum that all users needed and then create a roadmap.
The Standish Group looked at a subset of traditional teams which eventually delivered their work into production and asked the question, “Of the functionality which was delivered, how much of it was actually used?” “An astounding 45% of the functionality was never used, and a further 19% is rarely used”.
I’ve since learned of the Kano model (Customer Satisfied – unsatisfied vs. Needs fulfilled – unfulfilled), and feel that this justifies some of my thinking here.
An example of identifying an unspoken need
For the UI of this cargo airline schedules product, my particular personal experience was adding a filter to a search, so the users no longer had to know the type of each model of aeroplane (wide-bodied, narrow-bodied, etc.), and to sort on the model of plane in the schedule list looking for the type needed. No one asked for this functionality, but they did find it more helpful than the previous sort function, once they understood it. Unfortunately, although I didn’t get the opportunity to see users of the previous version in action without this feature I now realise that they would either have needed a list of these aircraft models or had to have learned them. The User journey is clearly more than just using software! I observe that this improvement is still unchanged on the product, which continues to sell globally.
In ‘Impact Mapping’ Gojko Adzic refers to the need to understand what job the user is trying to achieve and the desired changes in the job. It would seem that this was indeed what I was doing. However, I was unaware at the time that there was additionally a different type of user in some large customers who had a different job too. Clearly, something to watch for in future.
I also enabled users to set preferences, e.g. Kilometres or Miles, purely because I get frustrated having to make such choices every time I use a system!
Where I would start given what I’ve since learned?
From what I’ve learned subsequently I would use Jeff Patton’s outcome-focused ‘User story mapping’ as a way of transforming from Vision to Product backlog within an inclusive workshop. This provides structure and order whilst focusing on delivering Business value. Jeff actually cites Marty Cagan’s ten questions for Opportunity Assessment and suggests presenting them as a ‘canvas’ for discussion.
Carefully consider the use of an ‘MVP’
Jeff Patton is aiming for the Minimum Viable product (MVP) to demonstrate the minimal verified end-to-end process first before building on it. However, unfortunately, according to Simon Keen at the SyncHerts Meetup, many seem to use the idea of an MVP while misunderstanding the meaning of the words ‘Viable’ and ‘Product’. Keen defines Product as referring to something for multiple customers, who, inevitably have varying wishes, and that the Product is normally much more than just the software.
I feel that I achieved the minimal scope in my product, e.g. ignoring the pretty stuff that competitors were offering. And leaving the customised management capabilities for large companies for later on the Roadmap.
Our purpose is not to produce ‘stuff’, but to solve the customer’s problem at least cost
One of the less often observed of the 12 principles of Agile is to produce as little as possible ‘Maximise the work NOT done’. Not only does that save development effort but also, simplify the product, reduce subsequent support and maintenance. Sriram Narayan suggests that ‘Internal scope’, i.e. the delivery of individual stories, is actually more negotiable than the feature to be delivered. Minimal initial development enables increased feedback which should, in turn, increase the Business value for each feature. Also see Gojko Adzic’s Hamburger model.
Agile embraces the real world – Things change!
I’ve observed that there is a tendency to build huge Product backlogs. Robert Galen uses the analogy of Boulders, Rocks and pebbles to describe how the Product backlog should appear at any given time. Only work to be done now should be presented at User story level; the next work should be left at Epic level and work not due for a while at high level. Failing to do this causes User stories to require rewriting before coding, as more information comes to light as I’ve experienced.
Gil Broza says the Product backlog includes high-level statements of problems and solutions, yet there’s no commitment to deliver them; they are merely good ideas the team might get to. What matters is the Value / Cost relationship. We need to focus on the best value for the money and move to something else or stop altogether when we’re getting poor returns.
Keep updating the backlog as new knowledge arrives
Once a deliverable is shipped, we can measure the actual changes in actors’ behaviour and the impact on the overall objective. We can then re-evaluate our strategy and decide whether to continue working on the same part of the map or move on to something else. [see Gojko Adzic]
Since delivering that successful Cargo Flights product using an Agile approach I’ve learned that there are many opportunities to improve the development process, but we need to keep chipping away at the traditional project planning mindset that is getting in the way.