There is a lot of guidance out on the Internet about how to manage your requirements. The brand leader vehicle for a requirement is the User Story, which is essentially a place-holder for a conversation between two parties – someone who understands the problem or pain, and someone who can do something about it. This project is no different, we generally use User Stories as our requirements vessel. However, we also use other variations, as needs dictate – for example, Technical Stories and Spikes.
This project is being run in a way that’s compliant with the GDS lifecycle – it’s driven by user needs. So, with this in mind, how do our User Stories spring into existence? Especially as User Needs can represent very large things (consider stuff like Maslow’s work). Well, we think that we can look at User Needs in order to form hypotheses on what can be done to meet the need / alleviate the pain. These hypotheses need to be tested, and we do that with a mix of Lab testing, pop-up testing and specialist user testing (for example, we have good working relationships with Action For Blind People and we regularly test with them). Theories that have been proven are now at the next stage, and are ready to be analysed and expressed as a set of stories. These stories are usually fairly large (Epic or Theme scale), though there may be a few small, focussed quick-win items that are easily identified. These items go onto a list that’s ordered by timeliness – starting from things that need to be looked at sooner, and ending with things that’ll get looked at later. We call this list our Product Roadmap.
We have a regular process of reviewing and refining our Product Roadmap. Due to the nature of roadmap items, this refinement process is only matched to sprint durations (two weeks right now). We take a roadmap item, and as a team spend some time trying to understand it, break it up into smaller chunks that we need to prioritise over the remainder, and tease out these high priority elements and articulate them as User Stories. These go onto the Product Backlog. What’s leftover from the large Epic/Theme/Feature goes back onto the Roadmap. The separation of the Roadmap from the Product Backlog allows us to more easily focus either on a more strategic longer term vision, or on more immediate “next release planning”.
Once a User Story has been added to the Product Backlog, it becomes ready for thinking/analysis effort in order to understand it well enough to be sized and planned in an iteration. We’ve had to articulate a Definition-Of-Ready to capture this, as early on we detected inconsistencies in our understanding of the User Stories, which was leading to poorer estimates and a less predictable flow of work. We’ve called this process the “Three Amigos” (it matches what other projects in the area call this aspect of backlog refinement).
When it’s ready for estimation, we use the Planning Game to size the Stories. As we have a variety of backlog items – requirements based stories, technical stories, we use a set of reference points – for example we have a requirement based reference story that’s a “5” as well as a DevOps environment configuration reference story that’s also a “5”. This makes it easier to estimate using relative sizing as we can always compare like with like.
Once a story is sized, it can then be prioritised to the top of the backlog, ready for Sprint Planning.
Amateur Coach 