When it comes to Product Management, there’s no doubt that Agile is a highly effective methodology for iterating on product features and delivering “working software” in smaller batches. With smaller batches of work being delivered, we can more quickly understand faults in our processes and adjust our feature priorities, team members, or overall approach to our product backlog. Therefore, having a solid understanding of the role that the Product Owner will play is a vital competency to the success of the team’s “sprints”. When working within the “scrum framework”, a core skill of an Agile Product Owner is to spend time writing effective User Stories that can translate business value from the stakeholders and executive members of the organization to actionable tickets that designers and engineers can collaborate on. Let’s take a look at what makes up an effective User Story.
Scope and Structure
A User Story identifies a scope of work that should be completed to fulfill the requirements of a product feature or user goal. User Stories should be defined by taking a strategic approach to gathering the requirements or acceptance criteria, describing a user goal, and outlining the user benefits. While considering the scope, it’s also important to weigh in the effort it will take to design, develop, and QA the story. When looking at the bigger picture of story aggregation, a 2–3 sprint backlog of stories should all be prioritized to allow for rapid iteration and refining team velocity.
As a User Persona, I want User Goal, so that User Benefit.
When writing a User Story, it’s important to follow a consistent structure that ties in important details like the User Persona, User Goal, and User Benefit. Following this format will allow team members to clearly read what the goal of the story is, who it’s for, and why.
Orienting a User Story to target a specific User Persona is one of the first ways to bring clarity to who that product feature will be for. If you’re building a feature that users that will eventually interact with, it’s important to identify who those unique users are, to bring clarity to how the feature creates value. Identifying good User Personas can come from a variety of research including one-on-one interviews, focus groups, or case studies that can help unveil statistical trends, values, and pain points of different types of users. Asking the right questions about users can result in creating clearer User Personas.
When considering a User’s Goal within the context of a product feature, it’s common to collaborate with a User Experience Designer to help explore the creative possibilities around how the user will interact with the product. The goal should be clearly stated, specific, and phrased in a way that includes related nouns, verbs tied to functionality, and ordering depending on how a scenario might play through. Mocking up ideas with storyboards and prototypes can help to improve a user’s journey and solve problems they might currently be experiencing.
All User Stories should deliver value to the end user, hence the name “User” Story. When highlighting this value or benefit, it’s important to consider how it aligns with the business’s strategy and goals. Describe how a user will benefit from reaching their goal and connect it with how that benefits the business.
Ex. …so that I can invite a friend to join the platform to collaborate with. (user benefit)The friend can signup with a trial from my referral email. (business benefit)
When identifying requirements for a User Story, it’s important that we explicitly outline criteria that will help define a “definition of done”. This is typically best formatted in the form of bullet points, that each expose a criteria that must be met for the story to be finished and accepted. Each criteria item should be clearly stated using specific terminology that can be later tested during a QA phase.
Using the INVEST acronym can help guide a Product Owner to writing more effective User Stories.
A common software principle known as Separation of Concerns, refers to the isolation of problems or concerns that should be solved individually. This principle can also apply to a user story which highlights one particular feature closely and is kept independent. This isn’t always possible in some websites or applications, but it should always be considered.
The point of running Agile is to keep flexibility an option. An effective User Story should be negotiable, allowing for collaboration between designers, developers, and product owners. Each team member will provide special insights that can help refine details throughout the lifecycle of a story.
User Stories should be valuable to the User Persona they are targeting. If the story does not offer a valuable benefit after it’s completion, it would not be considered effective to the User Persona or the Business Organization.
When using effective User Stories, the team should be capable of estimating the effort it will take to achieve the scope of work. Clearly defined stories, that are sized appropriately help to improve their estimate feasibility.
User Stories should be sized appropriately which allows for clarity, portability, and team consumption. You wouldn’t build an entire wall at at once - lay one brick at a time.
User Stories should be worded in such a way that allows for testability. Clearly identify how the User Story will be tested using verbs and present participles like:
- Should hide modal window when clicking the modal’s close button
Writing User Stories is one of the core skills a Product Owner must master to help an Agile team become productive. They should write small, testable stories that target a certain type of users, outlining clear goals with specific criteria, that can be met with reasonable work effort by the Agile team and provide value to both the business and end user.