Four-part user stories improve communication between Product Owner and Development Team. They include context about the user and the sponsor of the work, which inspires creativity and better architectures from the team. They also make Grooming and Sprint Planning meetings faster, they yield more successful outcomes, and they facilitate Product Owners making better trade-offs. Are they better than sliced bread? I’ll let you decide.

Story Template

User stories are a short, structured format for Product Backlog Items in Scrum; descriptions of the functionality a Product Owner wants implemented. Explicitly naming the user and the value the user obtains forces Product Owners to consider users and helps developers rapidly understand what needs to be built. Historically, user stories have had three-parts: a stakeholder, a description of the functionality and a description of why the user wants it. I’ve found that adding a fourth part greatly improves ordering in the Product Backlog.

Here is a template for four-part user stories:

As a <stakeholder>,
    I <can do something new or different>,
    so I <gain stakeholder value>,
    and so <sponsor gains business value>.
Acceptance criteria
    - <stakeholder verification activity 1>
    - <stakeholder verification activity 2>
    - ...

<stakeholder> describes a person outside the team primarily served by the work. I use the term stakeholder because some people think users are only “end-users”. However, there are many potential users of a functionality. Other developers can use features from a component team. Customer service personnel can benefit from functionality facing end-users. Operations staff can benefit from configuration, scalability or disaster recovery functionality. By using the term stakeholder, I hope to make it clear that anyone benefiting from the functionality can be named here.

A user story should never name the Product Owner, Development Team or ScrumMaster as a <stakeholder>. Agile methods counsel us to provide functionality external stakeholders can try. Each Sprint offers the opportunity to experiment with the Scrum Team’s market. When Scrum Teams produce functionality that has no external value, they create risk: risk that the there is a bug, risk that the market will reject the functionality and risk that the team is over-engineering the solution. In short, you should not have a story that says anything close to, “As a developer, I have an API that makes it easy for me to write something useful, so I code faster, and so the company saves money.” Such stories create WIP, work in progress, which is considered waste in agile.

<can do something new or different> describes the feature, bug fix or “non-functional requirement” from the perspective of the stakeholder. This is a classic short-form feature description.

<gain stakeholder value> describes the motivator for the stakeholder. Why does the stakeholder want this feature? How does it make their product experience better, less costly, more useful?

<sponsor gains business value> describes the entity that pays developer team costs and the way that entity gains from implementing the feature. Does it reduce support costs? Decrease customer churn? Increase traffic? Improve reliability? Allow the company to charge more?

Here’s two examples describing the same feature request:

Requirement

Simultaneous configuration of multiple server instances with connection validation

Four-Part User Story

As an operations staff member,
    I can simultaneously configure multiple server instances and validate that connections between them can transmit state data,
    so I take less time starting up a fleet of servers and if there's a network failure risk, I can find it right away,
    and so Our Company can avoid slowing down at peak hours and retain its loyal customers.

These examples illustrate the clarity that arises in using a four-part user story. If we only have what is shown in the Requirement example, we don’t know who will use the functionality. Will this be done by a developer? How much time do they have to do this configuration? Can the connection validation be done manually? What is the cost if we don’t do it?

The description in the four-part user story provides context to help the developer answer these questions easily. With those answers, a developer can design and build a solution that better matches the underlying needs of the stakeholder and the sponsor.

Developers can negotiate with the Product Owner to build equivalent value in some less expensive or better way. For example, developers could offer to have new server instances obtain their configurations automatically from an already running cluster. They could offer to have the system continuously validate that connections are live (not just during configuration) and raise an alarm to operations staff when connections drop. These innovations are more likely to occur when developers have richer contextual information about a requirement.

Acceptance Criteria

Following a user story, include a set of Acceptance Criteria that a stakeholder could use to verify that the function was implemented. Why not just a list of tasks to complete? Because

• imagining stakeholders using your new functionality will help you compare how alternatives might better meet their needs
• they create a list of functional tests that could be automated or included in a test plan
• they provide better information to developers about what the Product Owner wants
• they offer a script stakeholders can use to verify the functionality.

Inviting stakeholders to verify functionality in a Sprint Review provides enormous value, turning a routine meeting into a regular user experience research session. By watching stakeholders interact with the functionality, both the Product Owner and the Development Team will discover aspects that confuse or irritate stakeholders, as well as aspects that delight them. This builds an intuitive sense into both Product Owner and Team that leads to better functionality and more satisfied stakeholders.

Here’s another example:

Four-Part User Story with Acceptance Criteria

As an operations staff member,
    I can simultaneously configure multiple server instances and validate that connections between them can transmit state data,
    so I take less time starting up a fleet of servers and if there's a network failure risk, I can find it right away,
    and so Our Company can avoid slowing down at peak hours and retain its loyal customers.

Acceptance criteria
    - Ops person can start 20 new servers by issuing a "start --servers 20 --config configfile" command.
    - Ops person can determine the state of all the new servers by examining the output
    - Ops person can verify that the new servers are live by clicking "Server report" on the control panel page

Consider how easily a test plan could be created from this specification. Note how much easier it would be to estimate this specification than the one under Requirement.

Summary

Try four-part user stories in your group. You may find that developers become happier and more engaged in creating new value. At a minimum, I think you’ll find that estimation becomes much faster.

References

Antony Marcano, Old Favourite: Feature Injection User Stories on a Business Value Theme, 2011. This article discusses the addition of business value into user stories in a different form than appears here.