user story grids
July 4, 2010 | Product Development, user story grid
Traditional approaches based upon producing large specification documents sometimes work, but more often have many problems. Some success has been achieved in recent years through the adoption of the Agile methodolgy by many projects.
I find that an enhanced user story template makes it easy to increase the quality of the story and share the intent.
[Persona] has a [problem/task to do] so that they can [Achieve/contribute to this Goal] with a [frequency of]
For example;
Felix [the occasional cinema goer] wished to find a film he can take the family so that they he can win some brownie points and have a nice time once a quarter
User stories are a big improvement over traditional dry documents containing functional, non functional requirements and business rules.
- User stories are nice because they focus on the product consumer Prioritisation and flow to developers (Good – developers like lists and the context and simplicity provided by stories)Tools to keep up to date for subsequent releases (Bad – without substantial investment – it is hard to maintain audit trails, some organisations use Microsoft Team Foundation Server)Tools to keep personas , commercials , market priorities , stories and releases tied together (tough – the user story model – a long list – does not lend itself to providing the full context of the product under design)
I love the user story approach , but also come from a background in product design where the whole picture needs to be considered. This means combining persona information with the market and commercial approach. Reducing the whole product effort to a simple flat list takes away some of the important structure and decomposition that the team need in order to understand and focus.
I have combined the classical Hierarchical Decomposition Method found in methods from the 1960s onwards such as Hierarchical Task Analysis and traditional systems analysis methods such as Structured Systems Analysis and Design (SSADM)
User story grid
These methods have some good features and some bad – just like any method. They have had some bad applications and some good. But the component of these methods I like is the decomposition of a product or problem into manageable chunks.
I was keen to achieve the same thing in my use of user stories to provide a breakdown hierarchically - but I also wanted to present everything in an attractive way on a single page to developers and business stakeholders.
The user story grid is the solution, I have been working with my team and we have produced more than 30 grids and the feedback has been terrific. I have also presented it at Product Camp 2010 in London
User Story
-
Step 1
Be clear what the overall product initiative is for and break this down into managable sub product areas. For large projects this is essential – for smaller projects a single grid may be sufficient
Step 2
Review your Persona library – if you do not have adequate personas to describe your target audience then now is the time to rectify that. Simple guide to persona development
Step 3
Prioritise which product areas you will focus upon – simple scoring may be enough to get a list of the most important product areas for study – but if that is hard to achieve - more robust scoring method may be required that involved scoring key attributes and then weighting them.
Step 4
For the product area under focus – produce an overall user story or EPIC that describes what using the product will be like in the market. You may find you need to produce several of these, as a minimum we find 2 are always needed, 1 for operational or back office staff – because all products need those people and one for product consumers. I split these onto different sheets to keep each sheet simple and allow a more accurate focus on the differences between personas for either operational users or for product consumers.
Step 5
For each user story grid – describe hat life is currently like for potential users in general, what will life be like once the first release of this product area is complete and what is the long term vision. It is essential to have a long term vision to share with the team, ensure alignment from a business perspective and also reduces the chances of developers coding a solution into a corner.
Step 6
Break the product up into a maximum of 5-8 main stories – these I no learn can be called Themes. This may still be quite high level
Step 7
For each Theme – select the Persona that is most relevant – place it at the top of the column with a short Persona Summary
Providing background to the theme
-
Prime Functionality – Insert here the prime function illustrated in this story eg edit, send, quite often this will be a Verb and noun phrase, eg Send the email – this can be a great resource also for managing and presenting the roadmap as the user story format is not well suited to roadmap presentation
-
Scenario - describe the context of what is going on in the persona’s to need this task completed
-
Considerations / Influencers - enter the considerations and influences that the developers need to know in order to design this correctly
-
Pain-points - what is typically bad about the way this persona achieves the task now, what goes wrong, what causes problems
Step 9a
identify the series of more detailed user stories that would need to be considered in order for this product to work – important to consider the product in an holistic way at this stage – don’t hold back.
Step 9b
Review all the detailed user stories – both on your own, as a team with other product managers and developers and also with all stakeholders to ensure the correct prioritisation is achieved. For smaller projects the entire prioritisation process of the user story grid can be achieved within the team. However, if the project is very large or involving significant amount of change in the business then a specific meeting to review prioritisation choices is recommended.
I have found that participants respond well to a simple MoSCoW model that we have extended to add Never. Won’t refers to not under consideration within the next release but could be developed as part of the product portfolio in future – whereas – Never – means this feature / story is not ever going to be offered by this company to the market. Obviously this can be a near infinite list – however the recommendation is to only use this category where there may be a misunderstanding or expectation that this story will be developed in the future and as a product manager you wish to ensure everyone knows it will NEVER be offered.
The user stories in the grid are marked up in words with the priority but also by colour.
