I’ve been on two Agile projects now where the following has worked. Not perfect but it helps to solve a problem that I’m seeing a lot at the beginning of projects. That is, how do you get from raw requirements and use cases into INVESTic user stories and epics?
Think – you’ve got a new product, you’ve got stakeholders in the room; they are brainstorming. They come out with a bunch of requirements. They leave. The dev team now has to figure out how to take this long list and turn it into develop-able requirements. We’ve got a lot of tools for dealing with stories once they are baked; estimation sessions, planning pokers etc. But the tools don’t seem so clear when you are trying to make sense of requirements at the inception of a project. So here’s one way I’ve seen that works:
Assuming you’ve got that list of requirements I mentioned earlier:
Move requirements into Features
Analyze the requirements as follows:
- True Need Analysis – Figure out what the real requirement is behind the ask. This is usually the domain of the BA. What is the user really asking for? For example, they may say they want a button that says ‘eject’ but what they really want is a workflow where they can stop the process at any point.
- De-Duping and Current State-ing – Figure out what requirements are really mimics of each other. For example, one user asks for an ‘eject’ button while another asks for a ‘Stop Process’ button. Merge when possible. Also – it could be that you’ve already built what the requirements are asking for – your current state meets the need. So give the requirements a current state pass as well.
- Grouping and Aggregating – How do requirements logically fit in with other requirements? What requirements are similar enough that they could be parts of the same feature in a product? Spend some time grouping those requirements together and give that feature a name.
- Acceptance – Determine how you’ll know that you’ve accurately completed this requirement. Check the language of the requirement because sometimes the requirements themselves can become acceptance criteria.
Prep the Features in a Spike
To fully Prep requirements, create a spike.
What is fully Prepped? It means that the feature has documented and clarified use cases, user personas who will verify that the feature meets their needs, high level technical specifications if needed, definition of done (preferable with acceptance criteria), and a priority as provided by the Product Owner. Basically it answers what we’re building, who we are building for, how they will use it.