When I tell people a big part of my job as a Product Manager is to write stories, I tend to be met with blank stares or quizzical looks. But if you’ve been anywhere near a project at Pivotal Labs, you’d know that stories are the life’s blood of the development process.
Simply put, stories are features that are broken up into small pieces of work. For example, “As a user, I want to log-in to the website, so that I can see my homepage.” These are written by PMs and logged in a Tracker tool. Dev’s then “pick up” these stories and use them to direct their work. A list of stories is called the Backlog and reading a Backlog should give someone a general idea of the product that is being built. There are a number of benefits to clients that stories provide.
Stories provide transparency. Stakeholders can read the stories in laymen’s terms, and ask questions about what is there and what is not.
Stories provide control. Clients can look at how stories are prioritized in the backlog and have meaningful conversations about why certain features are more important than others.
Stories help lower risk. Clients often have limited resources at their disposal and delivering smaller pieces of work at a rapid pace helps clients get their products in front of their audience faster.
When we work with clients that are new to working in an Agile environment, we explain user stories by presenting INVEST.
Out of these, the word “small” is a bit quixotic because the appropriate story size is a range with both an upper and lower bound. So what is a good story size and what are the tradeoffs? At Pivotal, we prefer to have stories that are estimated to take less than 2 pair days. This suits our goals, but because the size range can vary between methodologies and practitioners, we get a lot of questions around what is correct versus not correct. Here is a quick rundown of what we see at Pivotal when we use small stories.
Flexibility in planning, prioritizing, and cutting scope. One of the important skills we push our clients to develop is to see the complexity and cost of their vision.
Greater accuracy of the velocity. Velocity tends to be more accurate when the stories are finer grained, because there is less likely to be hidden complexity and issues.
Forces earlier and better understanding of the overall system.
As mentioned this process of turning stories into as small bits as possible has its trade-offs. Obviously the more moving pieces that you introduce into a process the more complex things can become. Each story becomes part of a larger picture and it is easy to get lost in the leaves. It’s also quite easy to have stories get duplicated, as well as have certain stories be blocked by work that is not completed yet. But PMs should rigorously audit their backlogs to make sure that all stories are relevant and usable. Most stories should be written within a few weeks of when a Dev would pick them up.
So what does this look like in practice? After an inception, the project team has a list of Epic stories. These are the higher-level stories out of which smaller stories are created. Here’s an illustration of this breakout process.
“Shopper should be able to recommend a product to a friend.”
After discussing the “how” of this story it can be broken up into smaller stories that capture facets of how a user will accomplish this task.
“Shopper can provide an email address of their friend.”
“Shopper can provide a customized message when recommending something to a friend.”
“A link is sent to the friend of shopper that links back to the recommended product.”
…and so on and so forth.
1 and 2 points story are generally the most common. 3 points story also occur regularly, but much less frequently. Higher points like 5 and 8 are rare and generally are because there’s technical unknowns and risks. At the same time, Pivotal Tracker assumes a starting velocity of 10 points, which also tends to be median for a pair. This translates to stories generally being about 1 pair day or less. Only rarely are stories at 2 pair days or more. Of course this is the estimate, and not the actual amount of time spent and this can change, shift or vary, but the team will learn to adjust estimates as the project moves forward.
Ultimately breaking up stories into the smallest possible increments does is makes it possible to predict with some accuracy when certain features will be complete. It’s never an exact science, and unforeseen things arise that can set predictions off track BUT Product Managers and Devs are able to control the size and breadth of stories. As development is often an uncertain practice, teams should grab onto the practices that help them gather more insight, more transparency and more control wherever and whenever they can. So…keep your stories small.
*Note: This post was started by Brendan Kao and finished/edited by Rosemary King an indeterminate amount of time later.