User stories are development tasks often expressed as “persona + need + purpose.”

It's tempting to think that user stories are, simply put, software system requirements. But they're not. 

A key component of agile software development is putting people first, and user-stories put actual end users at the center of the conversation. Stories use non-technical language to provide context for the development team and their efforts. After reading a user story, the team knows why they are building what they're building and what value it creates. 

User stories are one of the core components of an agile program. They help provide a user-focused framework for daily work — which drives collaboration, creativity, and a better product overall.

What Are Agile User Stories?

A user story is the smallest unit of work in an agile framework. It’s an end goal, not a feature, expressed from the software user’s perspective.

The purpose of a user story is articulate how a piece of work will deliver a particular value back to the customer. Note that "customers" don't have to be external end users in the traditional sense, they can also be internal customers or colleagues within your organization who depend on your team.

User stories are a few sentences in simple language that outline the desired outcome. They don't go into detail. Requirements are added later, once agreed upon by the team.

Stories fit neatly into agile frameworks like scrum and kanban. In scrum, user stories are added to sprints and “burned down” over the duration of the sprint. Kanban teams pull user stories into their backlog and run them through their workflow. It’s this work on user stories that help scrum teams get better at estimation and sprint planning, leading to more accurate forecasting and greater agility. Thanks to stories, kanban teams learn how to manage work-in-progress (WIP) and can further refine their workflows.

User stories are also the building blocks of larger agile frameworks like epics and initiatives. Epics are large work items broken down into a set of stories, and multiple epics comprise an initiative. These larger structures ensure that the day to day work of the development team (on stores) contributes to the organizational goals built into epics and initiatives.

Learn more about epics and initiatives

Why Create User Stories?

For development teams new to agile, user stories sometimes seem like an added step. Why not just break the big project (the epic) into a series of steps and get on with it? But stories give the team important context and associate tasks with the value those tasks bring.

User stories serve a number of key benefits:

• Stories keep the focus on the user. A To Do list keeps the team focused on tasks that need checked off, but a collection of stories keeps the team focused on solving problems for real users.
   
• Stories enable collaboration. With the end goal defined, the team can work together to decide how best to serve the user and meet that goal.
   
• Stories drive creative solutions. Stories encourage the team to think critically and creatively about how to best solve for an end goal.
   
• Stories create momentum. With each passing story the development team enjoys a small challenges and a small win, driving momentum.  

See how user stories work in Jira Software

Working with User Stories

Once a story has been written, it’s time to integrate it into your workflow. Generally a story is written by the product owner, product manager, or program manager and submitted for review.

During a sprint or iteration planning meeting, the team decides what stories they’ll tackle that sprint. Teams now discuss the requirements and functionality that each user story requires. This is an opportunity to get technical and creative in the team’s implementation of the story. Once agreed upon, these requirements are added to the story.

Another common step in this meeting is to score the stories based on their complexity or time to completion. Teams use t-shirt sizes, the Fibonacci sequence, or planning poker to make proper estimations. A story should be sized to complete in one sprint, so as the team specs each story, they make sure to break up stories that will go over that completion horizon.  

How to Write User Stories

Consider the following when writing user stories:

• Definition of “Done” — The story is generally “done” when the user can complete the outlined task, but make sure to define what that is.
   
• Outline subtasks or tasks — Decide which specific steps need to be completed and who is responsible for each of them.
   
• User personas — For Whom? If there are multiple end users, consider making multiple stories.
   
• Ordered Steps — Write a story for each step in a larger process.
   
• Listen to feedback — Talk to your users and capture the problem or need in their words. No need to guess at stories when you can source them from your customers.
   
• Time — Time is a touchy subject. Many development teams avoid discussions of time altogether, relying instead on their estimation frameworks. Since stories should be completable in one sprint, stories that might take weeks or months to complete should be broken up into smaller stories or should be considered their own epic.
   

Once the user stories are clearly defined, make sure they are visible for the entire team.

User Story Template and Examples

User stories are often expressed in a simple sentence, structured as follows:

“As a [persona], I [want to], [so that].”

Breaking this down: 

• "As a [persona]": Who are we building this for? We’re not just after a job title, we’re after the persona of the person. Max. Our team should have a shared understanding of who Max is. We’ve hopefully interviewed plenty of Max’s. We understand how that person works, how they think and what they feel. We have empathy for Max.
• “Wants to”: Here we’re describing their intent — not the features they use. What is it they’re actually trying to achieve? This statement should be implementation free — if you’re describing any part of the UI and not what the user goal is you're missing the point.
• “So that”: how does their immediate desire to do something this fit into their bigger picture? What’s the overall benefit they’re trying to achieve? What is the big problem that needs solving?

For example, user stories might look like:

• As Max, I want to invite my friends, so we can enjoy this service together.
• As Sascha, I want to organize my work, so I can feel more in control. 
• As a manager, I want to be able to understand my colleagues progress, so I can better report our sucess and failures. 

This structure is not required, but it is helpful for defining done. When that persona can capture their desired value, then the story is complete. We encourage teams to define their own structure, and then to stick to it.

Getting Started with Agile User Stories

User stories describe the why and the what behind the day-to-day work of development team members, often expressed as persona + need + purpose. Understanding their role as the source of truth for what your team is delivering, but also why, is key to a smooth process.

Start by evaluating the next, or most pressing, large project (e.g. an epic). Break it down into smaller user stories, and work with the development team for refinement. Once your stories are out in the wild where the whole team can see them, you’re ready to get to work.

https://www.atlassian.com/agile/project-management/user-stories

Win everyone over with your roadmap

The presentation of a roadmap can be nail biting for both developers and product managers; one party has worked hard to come up with a vision while the other party waits to see the unknown that is going to affect their work.

I felt this tension when I worked as a developer and I often found myself unsatisfied with the roadmaps product management put together. I didn't fully buy into the decisions, and I'd often walk out of a planning meeting with the sentiment of "Well, this doesn't make sense to me, but if they think so...", or even worse, a "We'll have to figure out things ourselves and make it look like what we do fits this roadmap.

You might argue the problem was likely me suffering from NIH (Not Invented Here syndrome) and you might be right. As a developer, I had a very strong opinion on what was the right thing to do. But now as a product manager, I see what caused this disconnect, and what general learnings product mangers can draw from this disconnect to hit a homerun with your next roadmap presentation. After all, if the technical team agrees with and understands the big picture, day-to-day design and implementation decisions will be made with the right context, and you’ll get the product you envisioned.

1. Choose substance over buzzwords

Whilst buzzwords like “big data analytics”, "machine learning," or “an Internet of Things initiative (IoT)” might resonate with business stakeholders as high-level anchor points, they aren't helpful and actionable items for technical teams. Engineering needs to know exactly what it is they're building, how it relates to current products, how it should be delivered, and who will use it in the end, and for what purpose.

Setting high-level themes is great for structuring the roadmap and context, but make sure you don’t stop there and have good answers for what is behind each high-level item. For example, if you've called a theme "intelligent services," make sure to break this down into key initiatives and epics that are needed in order to deliver this theme.

2. Set the right context

Technical teams need context for why you are building something on a roadmap. No technical team is going to say, "Just tell me what you want and I’ll build it." On the contrary, engineers need to see evidence for why you see demand for a feature. Let data speak, but also tell a powerful story from the perspective of your users. Use personas, and talk about some alternatives that you've excluded, and why. To help the entire team understand the roadmap the "why" matters as much as the "what."

3. Consider commitments carefully

If a feature doesn't seem well thought through or realistic, yet it is still on the roadmap, this should scream red flag. You don't want the technical team getting the impression that they have to build stuff just because you promised it to someone. This could be a commitment to a customer or because because "management wants it." So be wise about making commitments. Even if you have a forcing function behind yourself that requires a particular change, make sure you understand and pass on the rationale to the team, and stand behind it yourself.

4. Make realistic plans

A vision is good, but it’s even better if everyone feels confident that it can be achieved. The plan doesn't need to be precise, but if the first thing your development manager sees when looking at a roadmap is a huge bottleneck – for example, if the roadmap looks design heavy and frontend centered, but the team only has one designer and has struggled with frontend topics in the last few months – then you'll have he or she struggling with the roadmap throughout the rest of your presentation.

Make sure you do a reality check upfront with the team and play with what-if scenarios. You need to have answers, a clear plan of action, and concise consideration about the "how it can be done" before asking for everyone's commitment. 

5. Think big, start small

You need to be aware of where a product and team skills are today versus where you want them to be. It's great to advance into new fields, which might require new skills in the team or moving away from existing technology, but don’t just write down dreams of where you’d like to be in a year. Instead, think about how to get there realistically. Acquiring talent takes time, adopting new technologies takes time, and abandoning existing products requires clear commitments and a transition plan.

6. Build a business case

Business case? Yes. Technical teams care about businesses cases. Maybe not to the same extent as senior management, but an entire development team cares about why something is relevant to the business, if it produces real results, and how this will be measured. Tap into the business-street-smarts of your technical team. Everyone has a vested interest in the business succeeding as a whole, and it can be great source of feedback or additional ideas.

Also, full clarity on the business impact and seeing it happen can be a great motivator; driving results is satisfying beyond just having built and shipped a feature.

7. Balance mundane with motivating

Engineers want to build unique, innovative products that they can take pride in. If it's just the same old story others have told before, it can be demotivating. Make sure you do research to confirm that your story is as innovative as you think. Aside from demotivated developers, the business impact of the lack of innovation is even worse.

With this said, even roadmaps will always be a balancing act between exciting new features, and technically not too interesting must-haves that just have to be done. Try to make sure that even the mundane is motivating on your roadmap. 

8. Think beyond MVP and v1

Creating a minimum viable product, and then a version 1 is one thing, but there’s also everything that happens post-launch: operations, maintenance, feature requests from users, continuous improvements, and new versions of other products and/or platforms that are integrated. A quick think on what the challenges and obstacles might be after a launch will bring these to light without much effort, and engineers will be thankful that you didn't ignore these realities. Rough estimates suggest that the initial effort of building a new feature is often only a third to one half of the total effort spent on it over its entire lifetime. In other words: the aftermath is more costly then the initial build, and some "quick small things" become very costly in the long run.

9. Roll with the punches

Estimates are a good thing. They give you guidance, and are created to the best of a product manager's knowledge at each given point in time. However, many assumptions made for estimates turn out very wrong once you go into implementation or refine a design. Make sure you prepare and present the roadmap so that it’s flexible to changes.

10. Be open and honest

A roadmap is there to provide guidance. It’s not a detailed plan for execution and everyone on a software team knows that. There's no need to sell it as something different than it is. So if you don’t have all the details on a topic yet, be open about it. Share what you have, what the intention is, what the open questions are and highest risks that still need to be addressed. Point out areas that require experimentation and more research to nail down the "what." Just remember to account for this experimentation time in planning.

The bottom line?

Your team deserves a roadmap that clearly paints the big picture, but doesn't neglect realities. Your team also deserves a roadmap that is motivating, exciting, and has enough details so the entire software team knows what to do in the next 1-2 sprints with a feeling of confidence that they'll achieve great results with material impact for the business.

Cheat sheet: top 10 tips for getting buy-in from your technical team

A product roadmap is a shared source of truth that outlines the vision, direction, and progress of a product over time.

A product roadmap is the key to communicating how short-term efforts match long-term business goals. Understanding the role of a roadmap—and how to create a great one—is key for keeping everyone on your team headed in the same direction.

What is a product roadmap?

A product roadmap is a shared source of truth that outlines the vision, direction, priorities, and progress of a product over time. It’s a plan of action that aligns the organization around short- and long-term goals for the product or project, and how they will be achieved.

While it's common for the roadmap to show what you’re building, it’s just as important to show why. Items on the roadmap should be clearly linked to your product strategy, and your roadmap should be responsive to changes in customer feedback and the competitive landscape.

Product owners use roadmaps to collaborate with their teams and build consensus on how a product will grow and shift over time. Agile teams turn to the roadmap to keep everyone on the same page and gain context for their everyday work and future direction.

Who are roadmaps for?

Roadmaps come in several different forms and serve a variety of audiences:

Internal roadmap for development team: These roadmaps can be created in several ways, depending on how your team likes to work. Some common versions include the detail about the prioritised customer value to be delivered, target release dates and milestones. Since many development teams use agile methodologies, these roadmaps are often organized by sprints and show specific pieces of work and problem areas plotted on a timeline. 

Internal roadmap for executives: These roadmaps emphasize how teams' work supports high-level company goals and metrics. They are often organized by month or by quarter to show progress over time towards these goals, and generally include less detail about detailed development stories and tasks.

Internal roadmap for sales: These roadmaps focus on new features and customer benefits in order to support sales conversations. An important note: avoid including hard dates in sales roadmaps to avoid tying internal teams to potentially unrealistic dates.

External roadmap: These roadmaps should excite customers about what’s coming next. Make sure they are visually appealing and easy to read. They should provide a high-level, generalized view of new features and prioritized problem areas to get customers interested in the future direction of the product.

Why should I create a product roadmap?

The biggest benefit of the product roadmap is the strategic vision it illustrates to all stakeholders. The roadmap matches broader product and company goals with development efforts, which align the teams around common goals to create great products.

• For organizational leadership, the roadmap provides updates on the status of work and “translates” developer tasks in Jira into non-technical terms and a format that’s easily understood.
• For product owners and managers, roadmaps unify teams working on high impact product enhancements and allow them to communicate priorities effectively with adjacent teams.
• For the developers themselves, roadmaps provide a better understanding of the “big picture,” which allows team members to focus on the most important tasks, avoid scope creep, and make fast, autonomous decisions.

How do I build a product roadmap?

To build a roadmap, product owners should consider market trajectories, customer value propositions, strategic goals, and effort constraints. Once these factors are understood, the product owner can work with their team to start prioritizing initiatives and epics on the roadmap.

The content of a roadmap will depend on its audience - a roadmap for the development team may cover only one product, while a roadmap for executives can cover multiple products. Depending on the size and structure of an organization, a single roadmap may span multiple teams working on the same product. An external roadmap will often cover multiple products aligned with one point of emphasis or customer need.

The most important takeaway: create a roadmap that your audience can easily understand. Providing too much or too little detail on the roadmap can make it easy to gloss over, or worse, to too intimidating to read. A roadmap with just the right amount of detail and some visual appeal can earn the buy-in you need from key stakeholders.

Presenting the product roadmap

The product roadmap needs buy-in from two key groups: leadership and the agile development team. Presenting the roadmap is a great opportunity to demonstrate to key stakeholders that you understand the company’s strategic objectives, the needs of your customer, and have a plan to meet them both.

We have a dedicated page on presenting product roadmaps here. 

As you move through the project, make sure to link your team’s work back to the roadmap to build context. A tried-and-true method: break initiatives down into epics in the product backlog, then further decompose them into requirements and user stories. Establishing this issue hierarchy makes it easier for product owners and the development team to make decisions and understand how their work fits into the bigger picture.

Using and updating the roadmap

As the competitive landscape shifts, customers' preferences adjust, or planned features are modified, it’s important to ensure the product roadmap continues to reflect the status of current work as well as long-term goals.

The roadmap should be updated as often as necessary - this could be every week or fortnightly - so that it can remain an accurate source of truth. As we’ve all experienced at one time or another, a roadmap is counter-productive if it isn’t up to date. You’ll know if your roadmap needs to be updated more frequently because your stakeholders will start calling you for updates instead of consulting your roadmap. These one-off requests reflect a distrust in your roadmap, and a huge potential time suck.

However, on the flip side, you don’t want to spend more time updating the roadmap than is necessary to achieve alignment between stakeholders and within your team. Remember, the roadmap is a planning tool to think through how to build great products. If you’re spending time updating your roadmap that you could (and should) be spending on execution, think about changing your roadmapping tool to something more simple.

Best practices for the best roadmaps

Building and maintaining product roadmaps is an ongoing process to embark upon with your team. There are a few simple ways to set yourself up for success:

• Only include as much detail as necessary for your audience
• Keep the roadmap evenly focused on short-term tactics and how these relate to long-term goals
• Review roadmaps on a regular basis and make adjustments when plans change
• Make sure everyone has access to the roadmap (and checks it on a regular basis)
• Stay connected with stakeholders at all levels to ensure alignment

Ready to make your very own roadmap? Jump into the new roadmap feature in Jira Software and start to prioritize and plan your epics with your team.

Epics, Stories, Themes, and Initiatives

https://www.atlassian.com/agile/project-management/epics-stories-themes

Let’s say you and your team want to do something ambitious, like launch a rocket into space. To do so, you’ll need to structure your work: from the largest objectives down to the minute details. You’ll want to be able to respond to change, report your progress, and stick to a plan. Epics, stories, themes, and initiatives are precisely the tools you’ll need to do so.

By understanding how these popular agile methodologies help organize work, your team can strike a healthy balance between structure, flexibility, and launching rockets into space.

What are stories, epics, initiatives, and themes?

• Stories, also called “user stories,” are short requirements or requests written from the perspective of an end user.
• Epics are large bodies of work that can be broken down into a number of smaller tasks (called stories).
• Initiatives are collections of epics that drive toward a common goal.
• Themes are large focus areas that span the organization.

Agile Epic vs Story

In a sense, stories and epics in agile are similar to stories and epics in film or literature. A story is one simple narrative; a series of related and interdependent stories makes up an epic. The same is true for your work management, where the completion of related stories leads to the completion of an epic. The stories tell the arc of the work completed while the epic shares a high-level view of the unifying objective.

On an agile team, stories are something the team can commit to finish within a one or two-week sprint. Oftentimes, developers would work on dozens of stories a month. Epics, in contrast, are few in number and take longer to complete. Teams often have two or three epics they work to complete each quarter.

If your company was launching rockets into space, and wanted to improve the streaming service for your launches, you might structure your stories like the ones below.

Examples of an agile story:

• iPhone users need access to a vertical view of the live feed when using the mobile app.
• Desktop users need a “view fullscreen” button in the lower right hand corner of the video player.
• Android users need to be linked to apple store.

Learn how to configure stories(called issues) in Jira Software

The above stories are all related, and could all be considered individual tasks that drive toward the completion of a larger body of work (an epic). In this case, the epic might be “Improve Streaming Service for Q1 Launch.”

Organizing work into stories and epics also helps you and your team communicate effectively within the organization. If you were reporting your team’s progress to the Head of Engineering, you’d be speaking in epics. If you were talking to a colleague on your development team, you’d speak at the story level.

For complete definitions, examples and best practices, see:

• The Agile Coach: Epics
• The Agile Coach: Stories

Agile Epic vs Initiative

In the same way that epics are made up of stories, initiatives are made up of epics. Initiatives offer another level of organization above epics. In many cases, an initiative compiles epics from multiple teams to achieve a much broader, bigger goal than any of the epics themselves. While an epic is something you might complete in a month or a quarter, initiatives are often completed in multiple quarters to a year.

Example of epics in an initiative:

Let’s say your rocket ship company wants to decrease the cost per launch by 5% this year. That’s a great fit for an initiative, as no single epic could likely achieve that big of a goal. Within that initiative, there would be epics such as, “Decrease launch-phase fuel consumption by 1%,” “Increase launches per quarter from 3 to 4,” and “Turn all thermostats down from 71 to 69 degrees #Dadmode.”

At Atlassian:

Internally, we call our Initiatives “PC Tickets.” Project Central tickets are configured in Jira Software just like our epics. Each team takes their four or five most important goals for the year and makes PC tickets for each one. These PC tickets are used by the founders and management to understand all the work being done in the company.

NEXT: Learn how to configure Agile Epics

Initiatives vs. Themes

In many organizations the founders and management team will encourage the pursuit of some aspirational destination. These are the (sometimes super corny) goals announced each year or quarter, and themes are how you keep track of them.

• Initiatives are collections of epics
• Themes are labels that track high-level organizational goals

Initiatives have a structural design. They house epics, and the completion of those epics will lead to the completion of the initiative. Themes are an organizational tool that allows you to label backlog items, epics, and initiatives to understand what work contributes to what organizational goals. Themes should inspire the creation of epics and initiatives but don’t have a ridgid 1-to-1 relationship with them. A theme for a rocket ship company would be something like “Safety First.”

This is what themes look like in Portfolio for Jira:

At Atlassian:

One of our themes this year is Open Work. This is a push towards greater transparency, inside and outside of the company. My team is working towards this theme by doing a public retrospective on agile. We’re asking software developers to reflect on their agile development experience and tweet feedback with #RetroOnAgile. As a three month campaign, we’ve built an epic for this, and have labeled the epic with the Open Work theme.

Structuring your work:

Being agile and embracing structure are not mutually exclusive, and the structure laid out here is not one size fits all. Success is when you and your team understand these concepts and adapt them to your needs. For us, that's stories, epics, initatives, and themes. You can get started by learning how to set up Epics in Jira Software.