Once upon a time, in a land far, far away, lived a grumpy old wizard who loved spending time throwing stones at little kids who played near his mansion…
In just a few words, good stories transport you to a different place, stoke your imagination & involve you in the life and activity of someone you don’t know about. Almost immediately you begin forming an opinion about the key characters.
I love stories.
I was very excited when I first came across the term user story in Agile. This was not a user interaction, or a user feature. It was a story.
Ideally, the story would describe the user, his/her context, problem and gratification. It would make the user alive to the team trying to help him.
Sadly, from what I’ve seen across companies, not many user stories are written well.
Badly written user stories either have generic description of the user of the product, or end up being feature specs (eg: As a user, I want a green button labeled ON)
There are usually two reasons for bad user stories:
- The product owner doesn’t know much about the user and/or
- The engineering team treats the user story as a specification document
The user story should describe what the user wants to do. Instead, it ends up being whatyou want to do for the user.
Product owner and user research
I had earlier written about Agile as a concept vs. Agile as a process. A key limitation in treating Agile as a process is that the product owner is driven by the engineering team.
The key determinant is to keep the engineering teams executing, so the product owner ends up spending a lot of time ensuring the backlog is filled up in advance. This leaves little or no time for understanding the user.
Constrained by time, the product owner makes a generic outline of the user and anchoring stories around this.
If you treat Agile as a concept, the product owner is supposed to represent the customer’s voice in the development process. The product owner has to know his user’s needs well.
Many product owners, especially in B2B scenarios, end up figuring out user needs through secondary research, or based on quick conversations with a couple of target users.
Nothing is more dangerous (in the Agile environment) than a product owner who has limited knowledge about the user, but considers himself a representative.
Why?
Because the team ends up building a product that no user may end up liking. During the development process, the product owner argues eloquently about user needs, often mistaking that his/her view concurs with the user’s view. In the end, the product owner is satisfied with the product; no user is.
Users in real world often surprise you. If you’re in tourist mode, you often end up with the wrong conclusions.
I was once involved in building a mobile app for a low-end phone. I asked the product owner to draw some outlines of the user’s constraints and needs. When we reconvened, he came up with an observation that users were not bothered with data costs. “After all,” he said, “what difference does Rs. 10/- make to the mobile bill?” He was basing his argument on a chat with a couple of users across stores and one store employee.
Many of our target users were on pre-paid accounts, and rationed their mobile usage. They had dual SIM phones, and kept one slot for switching carriers who gave better deals. They would route incoming to the fixed SIM, and keep swapping the other SIM based on carrier packages where they could save money.
While we didn’t go about doing a detailed user study on this, I was able to cull information by speaking to a few college students, who were part of the TG, and triangulate it with information from friends who worked at carriers.
In this case, Rs. 10/- was an inconsequential amount to the product owner, but was a huge consideration for the actual user. If we had ended up missing this, we would have built a product that users would quickly have rejected due to high data demands.
Many engineering teams, especially those transitioning to the Agile mode of working, often insist on the user stories being complete, i.e. specified so that they can efficiently code out the solution.
This results in the product owner spending a lot of time writing and rewriting user story descriptions and acceptance criteria. As development progresses, the story backlog ends up having a lot of technical stories, bug descriptions and engineering terms. And in the process, the focus on the user’s problem is lost.
Ideally, a user story is designed to enable exploration of different ways of solving a user’s problem. It describes what the user wants, and a context in which s/he feels the need. The constraints are written in the acceptance criteria.
Given this, the technical team & designers can now explore multiple ways of solving the problem. The product owner can stay involved to judge which of the solutions serves the user’s need best.
In this approach, the team retains its flexibility in thinking up new ways of solving problems, often discovering better solutions than a didactic way of the specifications written by the product owner.
Of course this isn’t easy. It requires a lot of planning ahead to ensure there’s time for the exploration. It also needs maturity from members of the team. The team has to be comfortable that some of the work they do will be thrown away as they discover new solutions, and not stick solely to efficiency metrics.
Some organizations follow a dual-track method for Agile for this: a delivery and a discovery track. The discovery track is usually a small team that handles the experimentation. These solutions are often quickly tested with real users for quick validation.
One of the best ways I’ve seen to get out of the user story as spec is for the team to decide at the start of the project that they would keep a couple of experimental sprints, where they try an exploratory approach to build a solution based on understanding the user’s context without detailed specifications. Many times, these end up sensitizing the development team to the user they build for, enabling them to think for the user instead of thinking for the project.
One of the key beliefs in Agile is to know the user well, and build a product s/he likes. In my experience, I found that this often is key to building a great product.
I’d love to hear your experiences with user stories in the comments below.