If no one is talking about the User Stories of your team, you aren’t really using them.
2 years ago - 3 mins to read
As a User Story, I need to be discussed among the people that it may concern, so there’s a shared understanding about ‘what’ should be done and ‘why’ to benefit a ‘who’. Somehow it’s still common for experts to get assigned a User Story without them ever being part of any conversation with regard to the Story. In these cases the output of work is guaranteed to end up not meeting expectations.
Discuss User Stories with multiple expertises to get insight into a Story from multiple perspectives. (Photo by Tima Miroshnichenko)
People often seem to think it’s OK to solely rely on written requirements, scenarios or use cases. There’s no such thing as exhaustive documentation. It’s simply impossible to write down every detail that helps solve a complex problem. Even when you try really, really hard and would have unlimited time to do so. A User Story is made up of a ‘who’, ‘what’ and ‘why’. Each of those elements is meant to provide direction for experts to guide decision-making during work. Therefore shared understanding is key.
Solely using a ‘who’-label (‘As an Athlete/Patient/Store Manager, …’) without having a common definition for this type of person, doesn’t contribute to the value of using a User Story. Even if people pay attention to the ‘who’ in the Story, they will still try to come up with their own definition of an ‘Athlete’, ‘Patient’ or ‘Store Manager’. A well defined ‘who’ should always be part of your discussions. Don’t forget you’re trying to create value for these types of people. Knowing and understanding the ‘who’ will help your team to better understand the impact of their work. It will also allow for in-depth discussions if and how this type of person would value a certain ‘what’. If a decision can’t be made based on facts, this could indicate something valuable to figure out and measure.
There is no single solution, there’s always at least a couple. The ‘what’ in a User Story is a best effort attempt at (collaboratively) coming up with output that is expected to help reach a certain outcome because of the ‘why’. (Ideally you’ll want to have data to support a decision.) The ‘what’ should also allow for some level of interpretation. This way there’s always room for experts to determine what would be the best approach and adapt as necessary. Especially since new things are bound to be learned while working on the ‘what’.
Draw sketches, visualise words, and create prototypes to enrich discussions about the ‘what’ of a User Story. (Photo by Kaleidico)
The final element of a User Story is the ‘why’. It’s important that the ‘why’ describes a reason that’s especially valued by the ‘who’. Discussing the ‘why’ in a Story will help people empathise with the ‘who’ and better understand the impact of their work. Having different expertises to contribute to these discussions often broadens perspectives too. It also helps experts align decisions while they’re individually working on their part of the bigger whole. A ‘who’ should be valuing the ‘why’ enough to spend time and/or money for the investment needed to develop the ‘what’. While it’s impossible to precisely predict the workload for unknown work, the discussion about the User Story should provide some insight into expected work versus expected value returned. Not all Stories are worth pursuing.
User Stories should be kept up-to-date when new things are learned. (Make explicit who’s responsible for doing so.) Don’t forget to discuss the update with the experts involved. A User Story is a tool that is meant to facilitate discussion and provide direction. You’ll want to make sure that people are always working with information that is most likely to return value.
I’ve had programmers complaining about the amount of time spent discussing initially, until they see the positive impact it has on the value of their work. Shared understanding is key to developing value together.
