During these prep mini-courses and the main VCS program, we'll be advocating a blending of the SCRUM planning methods with XP programming tactics. Regardless of what you end up using on your own or with your team, it's worth spending a few extra minutes to make sure you understand User Stories.
Stories are particularly powerful because they tie together the user-first philosophy of User-Centered Design that we talked about before with the actual development of your project.
Even if you don't follow the project management process of SCRUM, creating user stories to guide your development work will be helpful. They'll force you to clarify what you're working on and break your project down into simple manageable pieces.
If you're following the User-Centered Design process from the Design mini-course, you've started your project by discovering who your users are and what their most important objectives are. User stories break up those larger goals like "I want to buy a coffee mug that says 'Hello, World.'" into specific achievable pieces. Taking apart a project and turning it into stories is an art, and it's best done when working directly with users.
At its most basic, your task is to turn those big user goals into little bite-sized mini-goals that can be developed. Each story is meant to fit onto a single 3x5 notecard to force you to be brief. That's why they are sometimes referred to as "story cards".
For practical reasons, teams often use sticky notes instead:
Source: Richard Banks
As an example, turn a larger goal like "I want to buy a specific product" into a series of individual steps like:
It's up to you exactly how specific you want to make these steps, but you'll get the hang of it once you've actually developed a few of them and found them to be either too narrow or too broad.
It's also worth noting that breaking down the larger problem into pieces like this is the heart of the engineering approach that we've been pounding into your brain for a while now. :)
The format of a user story is that it should be brief, in the language and perspective of the user, and contain the following:
Stories are designed to fit on a simple note card or post-it note. They have a brief title and are written in the following format:
As a [specific type of user], I want to [accomplish some specific goal] so I can [achieve some benefit].
This is valuable because it forces you to think in terms of what your user wants and why which will help you make the right development decisions along the way.
The other thing you need to add to your stories to use them for development work is their acceptance criteria (which usually goes on the other side of the card). That means writing down the specific tasks that need to be achieved in order for that story to be finished (or accepted by the client/user). For instance, if your story is:
"As a reader of this post, I want to subscribe to your newsletter so I can follow your blog"
Then the acceptance criteria, which would usually be on the back of the note card/post-it note, will include core paths and edge cases. It is meant to add detail to the conversation around the story but not (yet) serve as an exhaustive list of tests. The story above might include the following acceptance criteria:
These acceptance criteria form the basis for the things you'll actually need to write tests for during the development process (we'll cover testing in a separate lesson). Once the client agrees that all criteria are met, the story is accepted and you can move on to the next one.
The acceptance criteria should be as detailed as possible and always focused on the functional part of that story - what it needs to do. The how part is left as an exercise for the development team. Let's give a good and bad example here.
Say you have to implement a login form inside your app. A bad way to go about the acceptance criteria would be to go too technical about things. Eg:
POSTrequest to my API
You get the picture. Always focus on what it needs to do from a functional point of view. A better way to write the acceptance criteria would be:
/dashboardroute and grant him access to all the protected routes inside the app
Keep adding details. Thinking about as many use cases as possible can help a lot with bug prevention. And remember to always think and describe functional. Don't go technical. Acceptance criteria should read well to people who are not technical savvy.
A very important note about user stories. They should always deliver some business value to the Product Owner. Without that, the story being implemented is not that helpful.
This usually means that a story will include work that needs to be done both on the frontend side as well as on the backend side of the application. This is not to say that some stories will not be specific to one side of the coin (think about adding animations in your UI - entirely frontend task or integrating your server with another 3rd party service - entirely backend task). However, in order to get the most out of a particular feature, often work will have to be done in both directions. Good user stories phrase the functionality in such a way that, upon its completion, the Product Owner and the users have something they can use end to end and that adds business value to the product.
In order to illustrate the idea above, let's consider the above trivial example - the login form. And let's start with a not so good way to phrase a story around that.
We know that, in order to log in, we will need a form on the client side. So how about we create a story for the entire login form (maybe for the entire page/route?) and start working on that? Then we can also have a story for the backend functionality (API) and that's that, right?
Not so fast there! While it's true that we have more granularity this way (and granularity is a good thing when it comes to user stories), let's consider the business value that the completion of one of those stories adds up to the product. Well, what if I finish the front-end part but not the backend one? Or the other way around? Well, the functionality is incomplete without the other half. The Product Owner cannot approve the deployment of one without the other - it's useless to have a form if the API doesn't work, right?
Now you may think that you can do both in the same sprint. But often things will come up along the way that can change the dynamics of the sprint. Sometimes, work will not be finished during the 1-4 weeks of effort. Can we say we have completed only part of the functionality (if we finish the frontend story but not the backend one?). Then what is the value that the story adds to the product? The team cannot mark as complete something that, from a functional perspective, works only half way.
A better way to phrase that story would be: "As a user, I want to be able to log in so that I can use the application.". This is a phrasing that includes a functional, end to end flow (from the UI to the database) that will provide value for a potential user. Not all the things that need to be done (HTML markup/form, client-side validations, API implementations, etc.) can be specified as tasks or sub-tasks (depending on the tool you use) inside that story. When the team and the Product Owner mark the story complete, we know we have a piece of functionality that works and delivers value to the product. And now we're confident we can include that in the next milestone/release.
So remember to always phrase the user stories around a piece of functionality that is valuable to the user/Product Owner. Ask yourself - after I finish this, what will I be able to do in my application? Do I get any value out of this code? If the answer is not (or partly), then you should think again about how granular you're trying to be.
To learn more about writing good user stories, Check out this video (below):
Then read through this article from RallyDev.com by Ronica Roth. It's got good detail about the specifics of implementing stories.
If you still want some more tips, check out the Resources tab for more helpful links.
There are some specific ways that stories are used if you are implementing a formal development process like SCRUM. You probably won't go through all this added process if you're just building a website on your own, but it's useful to know your options. If you begin working as part of a team and need to start coordinating work among members and to meet time-based objectives, this will be more readily applicable.
As we said in the previous lesson, the project starts with the planning phase, when you break down the project into iterations and each iteration into stories. Once the team figures out what the user stories are, they go over each one and vote for how many Points it is worth. A point is a pretty subjective thing but it represents the developmental complexity of the story. Usually, they are either on a 1-2-3-4, 1-2-4-8, or a 1-2-3-5-8 (Fibonacci) scale. There are also the so-called T-shirt size estimations (XS, S, M, L, XL) - not using numbers, but still trying to give an estimate about the overall complexity of the story. It really doesn't matter what flavor you use. Any story that hits the highest number usually needs to be broken down into several stories.
The point of points (heh) is to estimate and track your progress as you are working through a sprint. It doesn't really matter on some absolute scale if you're giving the story the "correct" number of points -- as long as your team is consistent, you'll be able to use them for estimation.
Large groups of stories that combine to compose a particular feature are often grouped inside so-called Epics. In the product world, Epics are often considered "features significant enough you can write a press release about".
During the planning phase of the project and after you've broken the project into stories, you'll work with the client to prioritize these stories. Some features are essential and should be tested with real users ASAP, while others are more in the "nice to have" category for now. This prioritization determines what order they go into your product backlog. Your team will tackle the top stories of the backlog first and work its way through it.
At the start of each sprint, you'll have a certain number of total points that you're expecting to finish during that sprint. Each day that goes on, you will complete some stories and reduce how many points are remaining.
Your average daily number of completed points is called your velocity. In theory, if your velocity times the days remaining is less than the remaining points of the sprint, you're in good shape.
The chart of your remaining points over time is called the burndown chart. Since it shows how many points you have left to burn down each day, it visually shows you whether you're on track to finish the sprint or not. Note that points can actually be added if you add new stories mid-sprint or discover additional complexity.
See the image below of a burndown chart:
You should have a good feel for how you can break a project into stories and how those stories are used by a SCRUM team. Again, you may not use a full SCRUM process yourself but the exercise of producing user stories will almost certainly be helpful. Regardless, the tools we cover in the next lesson will help you organize your development work and stay on track.