The Who, Why and What of User Story Elaboration

The Elaboration process is one of the pivotal elements of our Agile process. At the start of every user story that we work on, the individuals working on that story will get together in an elaboration discussion. The purpose of the discussion is to ensure that we have a common understanding of the story and that there are no fundamental misunderstandings of what is needed between the team members.

Typically in my product teams the discussion is captured on a whiteboard in the forum of a mind map highlighting the key considerations around the story. The testers have the responsibility to write this up in the form of the acceptance criteria, risks and assumptions which they then publish and share to a wider audience. For the most part this process works well and allows us to create a solid foundation of agreement on which to develop and test new features.

Occasionally though we've been inclined to get ahead of ourselves and delve too quickly into technical discussions around a solution before we've really taken the time to understand the problem. The technique that I present here is one that I've found useful to inject a little structure into the discussion and ensure the focus is on the beneficiaries of the story and understanding of the problem.

The Cart Before the Horse

For some stories we encounter the developers involved may have some early visibility of the story and a chance to start thinking about possible solutions. Early visibility of a story provides a good opportunity to think about the potential problems and risks that various approaches might present. At the same time, bringing ready baked solutions into the elaboration also carries the risk of pre-empting the story elaboration by taking the focus into solution details too early. Occasionally I've seen elaboration meetings head far too quickly into the "Here's what we're going to do" discussion before giving due attention to the originators and reasons behind the request. Even with a business stakeholder representing the needs of the users in the elaboration, the early injection of a solution idea can frame the discussion and bypass discussing key elements of the problem.

In order to avoid this, here's a simple approach that I use in elaboration discussions to provide some structure around the session and ensure that we consider the underlying needs before committing to discussion of possible solutions.

Who

I start with a central topic on a whiteboard of the story subject and create the first mind-map 'branch' labelled 'Who'. This is the most important question for a user story, who are the beneficiaries of the story? If using a 'As a .. I want .. So that' story format should have a clear picture of the primary beneficiary, however that format contains precious little information to add meat to the bones. As a product company we have different customers fitting the 'As a' role who may have subtle differences in their approach and capabilities which the discussion should consider. Sometimes the primary target for the story is a role from one type of organisation, yet the feature may not be of value to the same roles in other types of company if it is not developed with consideration to them.

Also the "As a ..." format has no concept of ancillary beneficiaries who may be relevant when discussing later criteria. Whilst stories should aim to have a primary target role, we should certainly consider other roles who may have a vested interest in the means or method implemented. We can also identify these at this stage which can help to ensure the needs of all relevant beneficiaries are considered as the criteria for success are discussed.

By revisiting the "Who" question in the elaboration we can ensure that we flesh out the characters of all interested parties, including specific examples of relevant customers or users to give depth to the nominal role from the story title. Establishing a clear concept of 'Who' at the outset ensures the discussion is anchored firmly around the people we're aiming to help and provides an excellent reference point for the subsequent discussions.

Why

The next question that goes on the board is 'Why'. This is the most important question in the whole process, however until we've established the 'Who' it is difficult to answer properly. The why is where we explore the need that they have, the problem that they are facing. It is incredibly easy to lose sight of the problem as solutions are discussed to the extent that feature developments can over-deliver and miss core agile principles of minimising work done. Having the "Why" stage allows all of the members of the discussion to understand the problem and put key problem details on the shared whiteboard as an anchor for any subsequent discussion of solutions.

A commonly referenced technique for getting to the root value of a requirement is the '5 Whys'. Whilst this is a useful technique that I've used in the past for getting to the bottom of a request where the root value is not clear to the team, I think that it is heavyweight for most of our elaboration discussions. A single 'Why' branch on the board is enough to frame the conversation around the value that the target beneficiaries would hope to get from our development of that story.

Having 'Why' as the second step is important. David Evans and Gojko Adzic write in this post about changing the order of the 'As a... I want... So that' structure because it incorrectly places the 'what' before the 'why'. Instead they place the value statement at the front - "In order to .... As a ...I want". By following the process of adding branches to the elaboration board in order we similarly give the target value the appropriate priority and focus.

What

The 'what' relates to what the user wants to be able to do. This is where we really pin down the 'I want....' items that define the acceptance criteria. The primary objective of the elaboration is to look to expand beyond the one liner of the story definition. The testers responsibility here is to capture the criteria by which we will judge whether sufficient value has been delivered to deem the story completed to an acceptable level (NB I'm intentionally avoiding the term 'done' here as I have issues with the binary nature of that status.). The key here is that we are still avoiding discussing specific solutions. The "What" should be clear but not specific to a solution.

As well as the primary feature concept we're also looking to capture other important criteria here around what the beneficiaries of the story would expect from the new feature. This might include how it should handle errors and validation, usability considerations, scale-up and scale-out considerations and how it should behave with other processes and statuses within our system. The benefit of a mind map here is that we can revisit the previous branches as items come up in later discussion that merits revisiting so we can add items to the other branches if we identify items not previously thought of (such as system administrator stakeholder considerations) at this stage.

How

Finally, once the other subjects have been explored, do we consider the 'How?'. Some might argue that it is inappropriate to think about solutions at all during story elaboration. I'd suggest that avoiding the subject entirely, particularly if there is a solution idea proposed, feels contrived. As I discussed in the post linked earlier, we try to look beyond criteria during the elaboration process to identify potential risks in the likely changes that will result. This identification of potential risks can help to scope the testing and ensure we give adequate time to exploration of those risks if we pursue that approach. It is only one the 'Who, Why And What' have been clarified that we have sufficient contextual information to discuss the 'How' and the consequential risks that are likely to arise in the product as a result.

What happened to "Where?" and "When?"

These could be valid questions for the discussion, however I'd consider them optional in terms of whether to include them here. Both "Where?" and "When?" may be valid depending on the context of the story:

• Where could include whether an action is performed on a server or from a client machine
• When could include exploring the scheduling or frequency of execution of a process

I feel that the inclusion of these as branches in the discussion every time would make the process feel rigid and cumbersome, and would only include them if relevant to the subject of the story.

A placeholder for a conversation

I've often heard user stories described as 'a placeholder for a conversation'. That's an excellent reflection of their role. We can't expect to achieve the level of understanding necessary to progress a development activity from a one line statement, no matter how well worded, without further conversations. The elaboration is the most important such conversation in our process. It is where we flesh out the bones of the story statement to build a clear picture of the beneficiaries of the story and the value that they are hoping to gain.

The 'Who, Why, What....' approach to elaboration meetings provides a useful tool in my elaboration tool-kit to ensure we give the relevant priority to understanding these individuals or roles and their respective needs. I've run elaborations in the past where we 'knew' what we were going to do in terms of a solution, only for this to change completely as we worked through the details of the process here. In one example the solution in mind was too risky to attempt given that we needed a solution that was portable to an existing production release with minimum impact. In others we've revisited the proposed solution on the basis of expanding on the level of understanding that the intended user will have of the inner workings of our system. Even when a solution is apparent, nothing is guaranteed in software and plans can change drastically as new information emerges. Using this technique helps to avoid coupling our acceptance criteria too closely to a specific solution and rendering them invalid in the situations where it needs to be reconsidered later.