In the early days of software development there was the Specification, a document of what needed to be built with detailed instructions of exactly how the system should function and it was good.
Then as computers started to be used more widely it turned out that specification documents were too rigid as users started to use the systems and software in ways that the specification didn’t cover.
Around the same time, software developers started to realise that the way that software was built needed to be changed in order to accommodate changing user and business needs and thus agile was born and with it came a new way of documenting the intention of a system — the User Story.
User stories have a particular format that differentiate them from the specifications of the past, they focus on the user’s needs and use a set of Acceptance Criteria to capture the way the solution should and should not work.
User stories are also not a singular representation of the system. Instead, they are a component of a User Story Map, which contains many user stories across the entire system and divides them into ‘slices’; which form releasable chunks of the most valuable stories that need to be delivered, using whichever agile methodology is being used.
A common format for a user story looks like this:
AS A user
I WANT to be able to sort my search results by date
IN ORDER to get to the latest articles easierAcceptance Criteria:
- It allows the user to sort the results by date ascending
- It allows the user to sort the results by date descending
- It shows results without a date at the top of the list when sorting by date ascending
- It shows results without a date at the bottom of the list when sorting by date descending
- It does not show the date sorting option if there are no results
- It does not apply date based sorting by default
The user story is refined over many sessions where team members from all disciplines have a conversation about the story and add additional information as they learn more about the impact the story has and what work needs to be done to complete it.
The user story is ultimately a placeholder for these conversations and without the context of being part of these conversations it can seem a little ‘lightweight’.
The benefit of the user story being light on information is that it allows for a change in direction if it’s needed, as there may be things the team discover as they implement it that mean the implementation plan needs to change or the user’s or business’s priorities shift.
A good way of reducing the amount of unknowns that might be encountered when implementing a user story is to perform a time-boxed ‘spike’ where a subset of the team try to implement a small amount of the functionality and add more information to the user story to build a shared understanding in the team.
Solutionising with User Stories
One of the anti-patterns for working with user stories is to document a solution instead of the actual need for that solution.
This leads to user stories that look like this:
AS A user
I WANT to pay for my goods via express checkout with PayPal
IN ORDER to use my PayPal account to pay for my goodsAcceptance Criteria:
- The basket page shows the Express Checkout with PayPal button
- The user is prompted to log in before paying with PayPal so we can track who's paying via PayPal
- The user is asked to fill out their personal information before paying with PayPal if they don't have an account so we can track who's paying via PayPal
- The user is asked to fill out mandatory regulation information before submitting their order
- If the user is unable to pay for their goods due to PayPal returning an error (lack of funds, service error) then they are taken to the address entry stage of checkout with their address populated from PayPal
- Users who don't use the express checkout option go through the normal checkout journey
Compared to the example above you can see that there’s a predefined solution to the need for allowing users to pay with PayPal, which is to implement a particular payment flow.
The express checkout part of the story may be something that gives value to a larger part of the customer base if it was made independent of the PayPal story but the author decided that in order to have PayPal they also need to have express checkout.
There are a number of reasons why this anti-pattern is bad:
- You lose sight of the user need and the value that a solution to that need would bring to them
- You narrow the space that the team have for experimenting and innovating which can lead to bad development practices or weaken the product’s offering
- You become so invested in a story that it can become hard to adapt to a change in user or business need
- The user story stops becoming a placeholder for a conversation and starts becoming a specification
A side effect of a solutionised user story map is that a lot of the user stories are also highly dependent on each other, which then leads to difficulties in making slices, as more and more functionality needs to be introduced.
Why solutionising happens
Solutionised user stories are often found in companies going through a transition from waterfall to agile and as such they work in a manner most people call ‘wagile’.
The company may have embraced some of agile’s ways of working such as incremental changes and subscribed to a particular methodology such as Scrum in order to deliver quicker, but they haven’t managed to change the process in which those product increments are shaped.
There may be other factors that feed into this such as:
- Not trusting the team to be autonomous enough to deliver something valuable
- Egos. People are people and if you decentralise decision making then someone’s going to start feeling like they’re losing control and push back
- Vested interest, someone may have something to gain from doing something in a particular way. This can be financial or could just be that they want to use a particular tool or technique to solve the problem
Stop Solutionising
A good means of managing the transformation from waterfall to agile and not falling into the trap of ‘wagile’ is to hold reflective ceremonies such as retrospectives and work with the team if they raise an issue with solutionised user stories.
Using root cause analysis techniques you can work with the team to understand why these solutionised stories may be happening and work with the responsible team member(s) to get them onboard with using lightweight user stories.
This may not be an easy task as it may be that the team member(s) are very senior staff, used to dictating how to solve a problem; or in a distributed work environment they may be in a completely different timezone where they feel solutionising is the only means of getting their intent across.
Once you understand why solutionising is happening then you can start working on how to stop it and return to using user stories to capture the user’s needs.
Another measure you can put in place is to make sure that the definition of ready gives the team the power to ask for solutionised user stories to be reworked before they accept them.
You will still need to work with the person who is having their stories rejected to make sure they understand why the stories were rejected and help them get onboard with writing user need-focused user stories.