User stories

- User stories are a common technique to help teams understand precisely what they're building. From a requirements perspective, they are the start of a requirement but more importantly, the start of a conversation. Working in an agile way means we document a memory of a conversation in a lightweight style. To provide some context as we look at what good user stories look like, let's look at one from our online coffee store case study. User stories have a who, a what and a why. In this story, the who, is an online shopper. The what, is pay for the items in my cart. And the why, is so I can proceed to get items shipped to me. Next, let's look at a common model for determining if we have a well articulated user story. It's called the Invest Model. And each letter stands for an attribute of good user stories Let's dig in. I stands for Independent. Each user story should be able to be implemented on its own. Meaning that it can stand on its own and does not need to wait for other stories for the customer to see or experience the value. Notice that the incremental value each story provides is from a user point of view, independently. Creating a screen and then a database table to support the screen would not be an example of independent. Next is N. N is for Negotiable. Each user story should have just enough detail for the team to know what it's about. But also, it should have enough flexibility to discuss and evolve the design as the team learns and works. V stands for Valuable. Each story must be valuable to the user or end customer. Not a piece of what would be valuable if combined with other pieces. But truly a single piece of value from a customer perspective. Next is E for Estimable. The team needs to be able to estimate and have enough detail to move forward. This does not mean we know exactly how the story is designed technically in order to estimate. If it had this much detail, it would break the negotiable attribute. S stands for Small. If the story is being considered for a sprinter iteration, it need to be small enough for the team to consume, commit, and complete it. And last T. T is for Testable. The story is testable from a user perspective and has a good start on acceptance criteria. The invest criteria helps the BA's define and break down user stories and helps the product owner prioritize so the team can estimate and commit. Many teams run into times where it seems like a story just can't be written from a human perspective or they write technical stories, where the who is a piece of technology or something a technical resource needs to do for the product. With these technical stories, there are a few key guidelines to keep in mind. First, the product owner still needs to prioritize them. So the story must be written with an understanding of why its valuable. To do this, I like to reframe these technical tasks into a user story that still shows the business value. So, let's say that the team's technical lead recommends the database be upgraded. To write this story and prioritize it as a product owner, I would first ask the team, why they feel this is so important. Have this dialogue and get to an understanding of value. In this case, it comes out that the database upgrade is necessary to allow for the expected number of users on the app. As a B.A. you want to be able to write the story in the following format. This allows the product owner to actually prioritize how important this is, in the context of other business priorities, even though it's a technical task. I have some detailed user stories written in the Case Exercise file for you to look at. Communicating and writing user stories is a key skill that helps agile B.A's keep value top of mind and communicate value and user perspective to the team. These tips should help create user stories that generate great dialogue and move your team forward.