As a business analyst at BDO Digital, my job involves managing Agile project development to help our teams and clients work in harmony toward a common goal. When working with a client to develop a new software or feature, it’s my job to gather their requirements and documentation, and transition them in an Agile framework. We typically use Scrum, which involves producing work in a series of “sprints” and daily meetings — and User Stories.
If you’re just getting started with User Stories, this is a good place to start. User Stories are the vehicle to team collaboration and project success, especially when it comes to software development — although the Agile methodology and User Story concept can be applied to just about any kind of project management framework.
What Is a User Story?
A User Story is a statement that captures a problem from an end user’s perspective as well as the value behind solving that problem. Within an Agile project, each User Story represents a single goal, with each one entering production based on its priority until they’re all completed. This process continues until the entire project is done.
Breaking complex development projects into these smaller goals helps teams work effectively on complex projects. In software development, or any complicated project with many moving pieces, the purpose can often get lost, priorities can change on a dime and scope creep can happen to the best of us. Having individual goals — those User Stories — keeps the end user’s perspective at top of mind at all times, so everyone involved knows what they’re doing and why.
How To Write a User Story: Templates and Examples
When a request comes in, it must be translated into simple, nontechnical language that makes the clearest sense to everyone involved. Translating requests into User Stories is a simple matter of breaking the request into three vital elements: someone (who) wants something (what) for a reason (why).
That’s probably the most basic way of formatting a User Story, but you’ll find there are numerous ways to structure them. The format you use is up to you — just make sure it contains all three key elements — but typically, you’ll find User Story templates that looks like this:
As an <end user/persona>, I want <goal> so I can <achieve this value>.
As you can see, it’s a fairly simple formula. When it’s filled out with information, it could read something like:
“As an online customer (end user), I want the shop to remember my shoe size (goal) so I only see what’s available to me (value).”
From this foundation, you can make User Stories more granular and inclusive of certain conditions and actions. Here’s an example of a User Story that really narrows down the specific goals and values:
“As a prospect (end user), I want the website to remember me when I register for content and assets on a landing-page form (goal), given I’ve previously engaged with content offerings so I’m not answering the same questions, and the vendor understands my qualifications (value).”
This User Story also ropes in some additional value for the vendor, who benefits from gathering new prospect data with every interaction. In both examples, you can see how straightforward and
nontechnical the language should be, even when adding granular details. Focusing on the end user’s perspective and value is key to making sure the developers know what they’re aiming for — and what the client expects.
Acceptance Criteria: The Make-or-Break Component
You’ve created your User Story, the developers did their work and the clients have given their stamp of approval on the final product. The User Story is closed, right?
Not exactly. A story isn’t considered completed just because the clients accepted the finished product. Everyone will have their own “definition of done,” and while it’s tempting to accept a client’s happy reaction at face value, we need more confirmation that the goal has actually been satisfied.
This is where developers get involved in the User Stories — by providing the acceptance criteria. These are a set of conditions a product or feature must meet to satisfy the needs of clients, customers and stakeholders. Only when these conditions are verified in acceptance tests can the User Story truly be considered done.
The acceptance criteria not only help define success and failure, but they also serve as a group commitment to fulfill a specific request. If everyone sticks to their own unique idea of what “done” means, they may not have the clearest idea of what’s required on their end. However, when everyone understands and agrees on the acceptance criteria, it’s hard to deviate from that task at hand or the value that you’re aiming for. Once that commitment is made, everyone knows what they must do and what “done” truly means.
The Role and Benefits of User Stories in Agile Development
In Scrum, User Stories and their accompanying acceptance criteria live in the product backlog. This is a collection of all the User Stories created for a particular project — a master to-do list waiting for every item to be ticked. During our Agile ceremonies, we refer to these backlogs constantly to see which stories are still left to complete until the entire project is done.
User Stories enhance the project development process by keeping the end user’s perspective and desired value at top of mind across teams. This way, they can help ensure the value touches every decision involved in the planning and execution of production, even if last-minute obstacles or roadblocks arise.
The results?
- Improved collaboration. Writing User Stories and acceptance criteria enables better collaboration by getting everyone onto the same page. This way, they can agree on what they’re building and why it matters to the overall value of the product. Having a shared commitment makes it easier for teams to work forward together, rather than remain focused solely on their own tasks.
- Greater consistency. Every User Story is unique and will require a different amount of time and resources to complete. Typically, teams try to find an average level of commitment for each story and then write their stories to hit that average as closely as possible. By keeping every story as uniform as possible in terms of time and resources needed, project managers can much more easily maintain a steady flow of work and deliver on promised deadlines. If one User Story has a much higher level of commitment than the others, it likely needs to be broken up into smaller User Stories so the team can maintain a workable balance of tasks.
- Ability to prioritize. A key element of Agile development is working on the highest-priority items first, then knocking out the lower-priority jobs later. In Scrum, the product owner looks at the value of the work being asked for and the level of commitment required before deciding whether it goes into production or into the backlog. Weighing stories by their priority helps teams navigate that tricky moment when clients come in with urgent requests. Rather than taking urgent requests at face value and possibly derailing progress, the product owner can easily weigh and evaluate new requests to determine whether it needs action now or can wait in the backlog.
- Transparency and improved relationship with clients. One of the great things about Agile frameworks like Scrum is that they provide clients with iterative looks at what they’re asking for. Clients don’t always know how to articulate what they want — but they’ll usually know what they don’t want once the work has been done and they finally see it. User Stories help build a bridge between development teams and clients to make sure everyone understands what’s being asked, and whether the current course of production is satisfying those needs.
In an ideal world, every project is completed on time, within budget and with minimal headaches. But the words “ideal” and “project” rarely go together, especially when it comes to highly complex coding and processes. Even with the best-laid plans, there are plenty of things that can happen to throw off timelines or cause friction.
Clients can change their minds or make urgent requests that derail schedules. Tasks can take longer than previously thought, forcing teams to restructure their plans. The point is — when problems and challenges arise — it’s easy for the team’s focus to shift away from the most important element of developing new products and software: the value it delivers to the end user. User Stories help Agile teams schedule their work in manageable chunks and adapt to new information as clients learn more about the reality of what they’re asking for. With that done, Agile teams are able to churn out exceptional products on time and within scope — while also making the best use of their teams’ talent and resources.
As a bonus — there’s definitely a certain personal satisfaction that comes from checking off completed User Stories. Just like crossing out items on a to-do list, it feels good to know that your work isn’t only done; it’s done correctly.
Frank Coz is a Business Analyst at BDO Digital, working cross-functionally to help translate business strategy into technical requirements to developers. Now a Scrum-certified Product Owner and Product Master, he’s leading development teams to realize even greater levels of efficiency when developing features and solutions.
The post User Stories: Keeping End Users at the Center of Agile Development appeared first on DemandGen.
