Jacqueline: Today’s letter is U, and our topic is user story. User stories are very central to agile. Let’s break down a user story. A lot of you may be familiar with the format “as a,” where you identify the persona or the who, “I need/I want,” where you identify the problem or scenario, and “so that,” where the value statement is defined. Put it all together: As a _____, I want or I need _____ so that _____. The user stories are broken down into very small increments so that in your planning process, you can do multiple stories within a sprint or iteration. Never would you take a whole story and just complete one story in a sprint. If the story is so big that it will take the whole sprint, we go back and continue to slice it even more. Also, never would we tab a story to go past a sprint. That’s a definite no-no. If you have two-week sprints, your stories have to be less than two weeks so that you can do multiple stories. All of this is so you don’t have any surprises.
Too often when we take big chunks of work and we estimate them, when we start doing the work, we get surprised once we start looking at the code. It forces technical resources to look close enough at the requirement to make sure it’s not more than two weeks. Breaking it or slicing it down reveals unexpected or unsuspected conditions that often make the task much bigger than anticipated. So, it’s good that you’re forced to slice stories. It’s not just for the sake of slicing stories, but it’s for the sake of discovering any unknowns that might cause us to not be able to complete our commitment for the size of the story.
You don’t know this day one because requirements in agile are just-in-time. When you initially get the story, the story is what we refer to as raw. Then, as you add acceptance criteria and you start trying to plan and prioritize the story, you start roughing it out and ultimately refining it. Then, once you’re prior to putting in the actual sprint, you want to make sure it’s absolutely ready. That means you have enough acceptance criteria, examples, and even samples so that you and everyone on the team are fully confident in the estimate. Do whatever refining and finalizing you need to do to get a thumbs up from everyone that’s going to do the work.
Now, going back to the whole format of the user story, just want to recap. There’s the persona, which is the who. Who is the person that’s going to initiate, own the story, define the story, and be the subject matter expert for the story? The next component is the problem statement, the what. You have the who and the what. That’s what they need, what they’re going to use it for, and what they’re going to accomplish. Keep in mind that along with every what, there’s a what-if. Those are often what we know in traditional requirements as “alternate paths” or “negative paths.” Do your what-ifs early. These may spawn other stories, and that’s ok. Ultimately, there is the value statement. What’s the value? What makes it important? What are we solving with this story? And based on the level of effort, how much do we want to spend to solve this particular problem?
Even at the story level, agile is set up so that you evaluate the return on investment. Do you want to spend 20 story points? Do you want to spend 40 story points? That could be two weeks worth of effort by your whole team. How important is this story? How important is fixing this particular component or providing this particular feature? What is the return on the investment? And then there’s the show and tell. Throughout, you’re showing it to the customer, and in some cases, the customer is discovering new ideas, or seeing it makes them react and think of other things that might be extremely pertinent. All of this is welcomed in agile.
Once we successfully get to the point where the product owner says, “We have something of value that can be delivered,” well, it’s time to make sure that you have quality code, it’s cleaned up, it’s packaged, and it’s ready to go out and be promoted. There you have the full lifecycle of user stories. I want to give a special thanks to our resource. This is from Cowan Plus: www.alexandercowan.com. It’s called the “Best Agile User Stories.” He has a whole table of contents on creating user stories, knowing if you have a story, designing better stories, testing your user stories, developing stories and story maps, examples of user stories, and ultimately, how to create successful user stories.