BY: Karam A. Labban, CSP, CSM, SAFe Agilist, ACP, PMP, TKP
One of the most visible aspects of Agile Scrum is the user story card. These cards are present at the center of every Scrum ceremony. They are in the hands of the Product Owner walking into the first Scrum project team meeting and on the table as the Scrum team reads them and discusses them with the Product Owner in order to estimate the complexity of each story. They are on the backlog list as they get prioritized and are prominently visible on the Scrum wall as they get worked on and moved around the board. Later, they are front and center at the time of the demo and during retrospectives.
So it is no wonder that people want to be able to write excellent user stories. That would make sense because user stories are the building blocks of planning and executing an agile scrum project.
But, wait… while user stories are critical, they are not subject to a universally accepted quality check so they can easily be evaluated – especially by outsiders of the team. Plus, there isn’t much to work with in a user story. The structure is very simple: “As A (user), I Want To (short sentence with a verb) So That (the benefit to the user).”
As we can see, there is no room in the extremely short “story” for someone to push for perfection. I don’t want to make it more difficult, but Mike Cohn, a well-known author on user stories, regarded, in a blog entry on April 25, 2008, that the "So That" clause as optional part of the user story. I will come back to that later in this article.
So should one use their language skills and spend enormous time to come up with an abbreviated attorney-like speak for a story? Is there a guarantee this effort can’t be trumped with another language expert on the team – or by, God forbid, a management figure in the company wandering into the project room or into a project meeting?
Short and quick answer, no - not worth the time or the worries. User stories are made short by design to force the team to seek a conversation among themselves and with the PO throughout the project lifetime. They are made short to force estimation of effort and complexity without giving the impression that the time required is set in stone before the project starts.
While the above is true as far as what Scrum is, I can see where newcomers to Agile Scrum might still feel that they need to know how to ‘write a good user story.’ To help guide them toward that goal, I will briefly talk about two aspects of writing user stories. One more on the technical side, the INVEST method, and one about the whole Agile Scrum experience and how taking one aspect of the Scrum project and trying to perfect it flies in the face of what Agile Scrum was setup to address.
1) By all means make sure your stories not only adhere to the structure (As A ___, I Want to ____ So I Can ____), but also adhere to the INVEST guidelines (Negotiable, Valuable, Estimable, Small, and Testable). I would also add “Understandable” according to Sally Elatta of AgileTransformation.com. The addition makes very good sense because teams could fall into the mechanics of the INVEST evaluation and not have that group agreement that they are on the same page of what the story is all about.
The INVEST Guidelines are much documented and discussed during training sessions and on the internet so I will move on to the second point which is:
2) Why we should understand the motivation behind Agile Scrum and the ceremonies to see that User Stories are actually interconnected and not simple and isolated cards.
A user story card might be small and you can’t write everything you want on it, but you can’t underestimate its power as a conversation generator. From the time the PO writes the user story, to the time it gets in front of the Scrum team, to the time it gets prioritized and estimated, to the time it gets assigned to a sprint in a release plan to the time its sprint gets its turn, to the time of the demo and retrospective, it is making the team talk among themselves and with the PO and others.
In a traditional project management situation, the team and the project manager were asked to communicate, but they commonly fell back on the BRD and other documentation to learn what the user wants. These documents were written and signed-off on at the time even the user knew the least of what he/she wants. In Agile Scrum, we believe the requestor and the team learn more about what is valuable and really needed as the project proceeds and shippable features (stories) are delivered to the Product Owner.
The short statement of the user story and the small space of the card (including the confirmation statements on the back of the card) force the team to rely more heavily on the conversation throughout the project. By keeping the conversation going, new findings and new ‘lessons learned’ get into the conversation at the right time and without much formalities that might kill the spirit of welcoming change and acquiring new knowledge.
Now, one might say conversations are fluid and if nothing is documented then things can be forgotten even by the whole team. Not exactly. If something is that important, write it down and post it on the wall, but most likely, since the team is, preferably, co-located and stays together throughout the project, new acquired knowledge will not be forgotten. More importantly, because stories get their deep dive when their sprint comes up, any discussions, decisions, and ideas get implemented right away in the 2 or 3 week time-box sprint; therefore, taking the time for documentation loses any value one might have considered beforehand.
So, question each user story if it adheres to the UINVEST guidelines, but remember that User Stories are alive, are a work in progress, and by design can’t be and shouldn’t be pinned down and perfected when written. Perfection comes from the conversations at every turn and during every ceremony and every minute the team stays together.
And back to an earlier point, I agree that the benefits part of the user story is not a necessary thing, but if your Scrum team is new at it and have not matured through several projects, it is better to require the benefits part just so the conversation is more complete.
One last note, don’t overdo it when something that needs to be done is really not a user story and can’t be part of Sprint zero. In these cases, consider what Mike Cohn said in his blog on July 21, 2015 “If you find yourself writing product backlog items for parts of a system and are stretching to think of how to write decent user stories for those items, you might want to consider using FDD’s features.” Example, Merge the data for duplicate transactions.