What is a customer persona?

Customer Personas are fictional generalizations of your most valuable customers.

They help teams understand their customers by bringing together demographic information like age, gender, location, and income, alongside psychographic information like interests, frustrations, and personal or professional motivations.

What are user personas?

Now It might seem trivial at first, to come together as a team, mocking up what seems like fake dating profiles for your most important customers.

However, this exercise sets the foundation for other agile practices down the track, and its benefits are often undervalued.

Agile experts have called for more cross-functional teams, which means this knowledge of who the customer is, is no longer the sole responsibility of your Sales and Marketing team. Everyone is responsible for understanding who the customer is.

Teams that have a shared understanding and alignment around who is actually using the solution they are delivering are more likely to succeed.

Building customer personas helps teams to address the following questions:

• Who are our customers?
• What are their common behavioral patterns?
• What are their shared pain points (professional and personal)?
• What are their goals and objectives?
• What general demographic and psychographic information may influence their decisions?
• What drives them to make purchasing decisions?
• Is the customer the buyer or decision maker?
  

There are two steps you can take to answer these questions and start to identify who your customer personas are:

Firstly, broadly define your personas

It’s not crazy to think that most companies will have some broad idea of who at least some of their customer personas are. This knowledge is accumulated over time and is based on customer feedback, support requests, conversations/interviews, and initial market research.

This knowledge is not to be underestimated and is a great starting point before looking towards analytics to flesh these personas out into more specific detail.

Secondly, look towards insights and analytics

Once you’ve come up with a few customer personas, it’s time to flesh them out with qualitative and quantitative data.

So where can we find this information?

Look at sources like:

• Website Analytics
• Facebook Insights
• Customer Surveys & Polls
• Industry reports
• Customer Interviews or
• In-Product Analytics

After looking through all of this information you can map back the data against your original assumptions.

By the end of the exercise, you and your team should have a pretty good idea of who your customers are, and how to best service them, communicate with them and build solutions for them.

Customer personas in Jira

Once these personas have been developed, the challenge is choosing where to store them.

Making the personas highly visible should encourage your team to consider them each time new work enters the backlog. You want them to think, “What would Sam the System Administrator think about this new feature? Would she use it? How would she communicate its benefits to her team? What are some of the problems Sam may encounter on first use?”

That’s why we created an app for Jira - Easy Agile Personas.

Easy Agile Personas enables you to create and keep your user personas in Jira alongside your work, so the entire team can keep the customer in mind.

Whether you choose to use Easy Agile Personas or not, the customer personas you develop are vital to building user story maps.

Try it now

Sometimes the idea of writing user stories can seem like another "thing" on top of an already busy workload. But for software development teams who are looking to lead their own improvement and deliver software that works for their customers, writing effective user stories is the first step.

If you’re reading this post, it means you want to learn what will work best for the people who use your software, and improve how you approach software development. That's great! Our goal at Easy Agile is to help you do that.

So let’s start with why good user stories are important.

Why write user stories?

You may wonder why you should write user stories rather than writing features or tasks instead.

If this sounds like you, you might not yet have seen the value of writing user stories, and that they serve a very different purpose to writing features or tasks.

It’s easy to get buried in a cycle of feature development that lacks context. The objective becomes more about clearing your way through a large backlog than building solutions that add value for your customers. To build successful software, you need to focus on the needs of the people who will be using it. Your human customers. User stories bring that context and perspective into the development cycle.

What is a user story?

A user story helps agile software development teams to empathize with their customers. Written from the customer (or user) perspective, user stories help the development team understand what they need to build, and why they need to build it.

User stories are simplified, high-level descriptions of a user’s requirements written from that end user’s perspective. A user story is not a contextless feature, written in “dev” speak.

A User Story = the 'what'

A user story describes a piece of functionality from the point of view of the user.

User stories divide features into business processes.

A task = the 'how'

Tasks are the activities that need to be performed to deliver an outcome.

Tasks are individual pieces of work.

How do we write user stories?

You might like to think of a user story as an ‘equation’:

As a [user] + I want [intent] + so that [value]

Let’s break this down further;

As a [user] — this is the WHO. Who are we building this for? Who is the user?

I want [intention] — this is the WHAT. What are we building? What is the intent?

So that [value] — this is the WHY. Why are we building it? What is the value for the customer?

Let’s look at a few simple examples;

As an internet banking customer

I want to see a rolling balance for my everyday accounts

So that I can keep track of my spending after each transaction is applied

OR

As an administrator

I want to be able to create other administrators for certain projects

So that I can delegate tasks more efficiently

Following this equation, teams should make sure that their user stories are ticking all of the following checkboxes:

To write successful user stories:

• Keep them short
• Keep them simple
• Write from the perspective of the user
• Make the value or benefit of the story clear
• Describe one piece of functionality
• Write user stories as a team
• Use acceptance criteria to show an MVP.

Acceptance Criteria

User stories allow agile teams to balance the needs, wants and values of their customers with the activities they need to accomplish to provide that value.

The link pairing these two things together is acceptance criteria.

Acceptance Criteria or ‘conditions of satisfaction’, provide a detailed scope of user requirements. They help the team understand the value of the user story and help the team know when they can consider something to be done.

Acceptance Criteria Goals

Acceptance criteria should:

• clarify what the team should build before they start work
• ensure a common understanding of the problem or needs of the customer
• help team members know when the story is complete
• help verify the story via automated tests.

Let’s look at an example of a completed user story with acceptance criteria:

As a potential conference attendee, I want to be able to register for the conference online, so that registration is simple and paperless.

Acceptance Criteria:

• Conference Attendance Form
• A user cannot submit a form without filling out all of the mandatory fields (First Name, Last Name, Company Name, Email Address, Position Title, Billing Information)
• Information from the form is stored in the registration database
• Protection against spam is working
• Payment can be made via Paypal, Debit, or Credit Card
• An acknowledgment email is sent to the attendee after submitting the form

With this in mind, teams should make sure that their acceptance criteria considers all of the following:

• Negative scenarios of the functionality
• Functional and non-functional use cases
• Performance concerns and guidelines
• What the system or feature intends to do
• End-to-user flow
• The impact of a user story on other features
• UX concerns

Acceptance criteria should NOT include the following:

• Code review was done
• Non-blocker or major issues
• Performance testing performed
• Acceptance and functional testing done
  

Why?

Your acceptance criteria should not include any of the above, because your team should already have a clear understanding of what your Definition of Done (DoD) includes, for instance:

• unit/integrated testing
• ready for acceptance test
• deployed on demo server
• releasable

Writing effective user stories is a valuable practice that will help you and your team deliver software that stays relevant for your customers.

When you embrace user stories as more than just another task on your checklist, but instead view them as an essential tool for creating context and value for your projects, you can stay connected with your ultimate focus - your customer.

Transform your backlog into a meaningful picture of work to gain context for sprint and version planning, backlog refinement, and user story mapping.

Stay focused on your customers

Easy Agile TeamRhythm

Are you keen to ensure your company is customer-centered? One good way to do that is to build personas.

Whether you’re a product owner, marketer, or salesperson, writing your company’s personas is kind of a big deal. (So, probably don’t delegate this job to the intern...)

That’s because your personas can be used to:

• Brainstorm new ideas
• Decide what products and features you should prioritize
• Better target your advertising and marketing creative
• Connect better with sales prospects and recommend the best solution to match their goals, problems, and pain points

Your personas will impact nearly all parts of your organization, so it’s important that you get them right. We know a thing or two about how to create personas (you might even say we’re experts 😏), so we’ve created this little guide to help you create yours like a pro.

Follow our 9 simple steps and you’ll end up with powerful personas that your whole team can use.

Ensure your team are aligned around customer archetypes with

Easy Agile Personas

Free Trial

1. Do your research

The best place to start is with your existing customers and prospects. You could run interviews and focus groups to find out more about who your customers are and what they want. Or create an online survey - you can set these up for free in Google forms.

Ask your customers about:

• Their age
• Their location
• What they’re qualified in
• Their title or job role
• Where they work
• Their family life
• How they’re currently using your product (or other products)
• What’s bothering them about your product (or other products)
• Relevant tasks they struggle with
• What they’d like to achieve in their work/life right now

Tip: it can sometimes feel a bit awkward if you ask personal demographic questions, so you could instead sum them up with one question: “How would you describe yourself?” This allows each respondent to decide how much detail they give you, and you might get some really valuable insights from an open-ended question.

Other research methods include:

• Analytics- Google analytics and social media analytics will usually display demographic Look at your analytics
• Forums- Join forums and closed groups where your audience likes to hang out, ask questions, and share about problems that are relevant to your product or service (just make sure you set a time limit for yourself so you don’t accidentally fall down a Reddit/Quora rabbit hole)
• Talk to your colleagues- Try to get your whole team involved and talking about your audience, especially the ones who regularly interact with customers

2. Analyze the data and identify your personas

Now that you’ve done the research, it’s time to figure out what it means. Keep an open mind as you look at the data because you want to create real personas, not something that backs your own internal narrative or the path you’ve been on until now.

Look for patterns in the data and see what the similarities and differences are. From here, you should be able to identify 3-5 distinct persona types. At this point, you might be tempted to create eleventy million personas, but don’t. You want to cover all your key user and audience types, and get reasonably specific.

Usually, less is best when it comes to personas because it means you can be more focused. After all, you can’t do everything and you know what they say… if you target everyone, you reach no one. The more your product and marketing is tailored to a specific group of people, the more they’ll be drawn to it. This could mean you’ll need to exclude some audiences from your personas who aren’t as good of a fit for you, and that’s okay.

3. Find a persona tool or template

Ideally, you’ll use an app or system that creates personas (like Easy Agile Personas for Jira). That way, you can integrate your personas into your processes, you won’t have to fiddle around with formatting, and they’ll be easier to update.

Some people have persona templates in google docs or Confluence.

Try Easy Agile Personas

4. Make them human

Before you put pen to paper, it’s a good idea to source a photo that helps define who your user persona is. That’s because the more authentic your persona, the easier it will be to relate to them and have empathy with them. And the easier it will be to write about them and come up with their story. When choosing your photo, try to find something that doesn’t look like a stock photo.

Next, give your personas real names that fit their demographics. Try to avoid boring cliches, but if you need some namning inspiration, you can trawl through the lists here.

In the personas, include information that helps you understand them as a person. You don’t need to share their full life story, but adding little details about their personality and motivations can help bring them to life.

5. Write your personas

When writing your personas, it’s all about telling their story (the TL;DR version). Depending on how you plan to use your personas, you might include details like:

• How their day is structured
• How they got to where they are now (in life/career)
• What they’re currently thinking about
• What keeps them up at night

Key sections could include:

• Name
• Demographics (like gender, age, location, qualifications, occupation, income, marital status, and kids)
• Goals/needs
• Values
• Information sources (like books, podcasts, news sites, blogs, TV, radio, thought leaders, and social media channels)
• Technology (including devices, browsers, and software/apps)
• Pain points, fears, and objections
• Personality traits (you might refer to DISC, Enneagram, and even Love Languages)
• Skills and tools
• Quote (a sentence or two in their own words that captures their thoughts or position, ideally a survey answer or quote from interviewing one of your customers)

You don’t have to use all of the above sections. You’ll need to keep your personas succinct (1-2 pages), which means avoiding fluff and editing out details that aren’t relevant or useful.

6. Refine

Now that your personas are written, it’s time to involve the rest of your team and get feedback on the personas. Many of them will have different perspectives on who your personas are and what your audience’s key problems and pain points are. So, let them poke holes in the stories and add other important details you may have missed.

There’s also a side benefit to refining your profiles with the help of your team members. If they’re involved in creating the personas, they’ll be much more likely to use them at the end.

7. Make them pretty

Scrappy personas can work, but if you create a better user experience, your personas will probably get used more often.

You can jazz up your personas with icons, illustrations, and brand colors. Add graphs and charts to visually represent data (like where your persona sits on a personality trait scale). And use headings to break the persona up into sections and make it easier to scan. Dot points, bolding, italics, and highlights can also help key information to stand out.

8. Incorporate them into your processes

Your marketing, sales, and development teams can all do better work when they use personas. So make sure that your shiny new personas are incorporated into all relevant business processes and made accessible to the whole team. Upload them to the cloud, link them to your project management tool (like Jira), and ideally, your user stories and backlog to add context there.

9. Notice the difference

With personas, your teams are equipped with a much better understanding of your users and audience. The impact of this could be that:

You’ll become more user focused

Personas force your team to think about the user first, empathise with your customers, and see them as real people with real needs. For example, your team might want to work on a new feature that allows users to login using Facebook (everybody else is doing it!), but first they check to see how each persona would use this feature. Turns out, none of your personas are heavy Facebook users so it’s unlikely this feature would get used. Instead, your team decides to prioritize updates to the dashboard that could help two of your personas achieve a specific goal.

Your product will improve

If you’re focused on what your users want and need, your product will get better. Linking new features and work to what your personas need will help shape your product and make it more valuable over time.

You’ll see the value in your work

A task becomes more than just a thing on your to-do list when it’s linked to a persona. Your team aren’t just marketers, salespeople, and developers - they’re problem solvers.

Your marketing is more relatable

Personas help your marketing team know your customers better - their problems, goals, desires, and even how they talk. Your marketing team can use these insights to create marketing collateral that’s more relatable and engaging - that talks directly to your personas.

Your comms become more aligned with your releases

For example, your marketing team could filter all of the issues scheduled in an upcoming release by Persona. They might see that the majority of stories the development team will be working on directly relate to the Busy Mum persona. Having this information allows them to tailor their go-to-market communication to the Busy Mum persona, which can help warm up this audience, ready for the new release.

You’ll have your priorities sorted

You’ll be able to prioritize better and justify your actions by bringing it back to your personas. Instead of following your own agenda, your customers’ priorities become your priorities. You can sort tasks by which persona it will benefit and by how much (in Easy Agile Personas, we have an “Importance to Persona” custom field). For example, you might see that your team hasn’t worked on any of theStay At Home Dad persona’s stories for a while, so you shift gears to work on his top priority feature.

That’s why great personas should be your #1 resource when making key business, product, and marketing decisions so that you always look at things through the lens of your customers. Now you’ve got your personas, go forth and create!

Try Easy Agile Personas

If you’re using Jira, we have a super simple way you can incorporate personas into your workflow 👇

Easy Agile Personas is our latest solution for teams that use Jira. Capture personas alongside your team’s Jira board and make it easier for your team to stay aligned on priorities and focus on the most important thing - your customers!

Try the 30-day free trial and see how easy it is to build personas into your team’s everyday tasks!

Easy Agile Personas

It might seem trivial at first, to come together as a team, mocking up what seem like fake dating profiles for your most important customers. However, this exercise sets the foundation for other agile practices down the track, and its perceived benefits are often undervalued.

Teams that have a shared understanding and alignment around who is actually using the solution they are delivering are more likely to succed.

Agile practices have called for the development of cross-functional team members, which means this knowledge of who the customer is, is no longer the sole responsibility of a (traditional) Sales and Marketing team.

Definition: What is a Customer Persona?

Let’s dive straight in.

Customer Personas are fictional generalisations of your most valuable customers. They help teams understand their customers by bringing together demographic information like age, gender, location, and income, alongside psychographic information like interests, frustrations and personal/professional motivations.

Building customer personas helps teams to address the following questions:

• Who are our customers?
• What are their common behavioural patterns?
• What are their shared pain points (professional and personal)?
• What are their universal goals/objectives?
• What general demographic and psychographic information may influence their decisions?
• What drives them to make purchasing decisions?
• Is the customer the buyer / decision maker?

Why are Customer Personas Important in Agile Software Development?

I think by now, you’re starting to see that building customer personas provide value to the team, but just in case you’re not quite on the customer-persona train, here are a few really important reasons:

Customer Personas help identify customer specific needs and wants:

This understanding ensures that Product Managers, Designers, Developers etc. are delivering solutions that actually address real user challenges.

Personas provide a “face” to the user story:

This helps the team have a shared understanding of who their customers are and creates buy-in and empathy.

Targeted/Segmented MarComs:

Understanding your customers needs, challenges and behavioural influencers, allows you to better understand what content will appeal to them best, by segmenting your customers by persona type and tailoring your marketing communications to each specific group.

Before We Start: Customer Persona Overview

Let’s look at an overview of what “goes into” building customer personas and some discovery questions to help get you started.

As you can see, a lot more thought goes into creating customer personas than simply guessing and gut feeling. So how do we go about defining all of the elemets listed above, and more specifically, what questions are we hoping to answer about our customers along the way?

Let’s take a look at some discovery questions:

Location: where do people from this persona live?

Age: what is the average age/age range of this persona?

Gender: are people representative of this persona predominantly male or female?

Relationship Status: Single? Married? Children?

Interests: what are the general interests of people in this persona?

Language: what is the primary language used by people in this persona?

Favourite Websites: where do people in this persona go to learn new information?

Education: what level of education do they have?

Job Title: what is/are typical job titles for people in this persona?

Responsibilities: what does a typical work day look like for people in this persona?

Frustrations: biggest challenges for people in this persona?

Motivations: what motivates people in this persona to be successful?

Personal/Professional Goals: what do they wish to achieve?

Getting Started: Building Customer Personas

It’s time to start creating our personas, and we’re going to break the process down into 2 steps;

• Broadly define your personas
• Look towards analytics and layer results

1. Broadly Define Your Personas

It’s not crazy to think that most companies will have some broad idea of who at least some of their customer personas are. This knowledge is accumulated over time and is based on customer feedback, support requests, conversations/interviews and initial market research.

This knowledge is not to be underestimated and is a great starting point before looking towards analytics to flesh these personas out into more specific detail.

Keep in mind that a single team member will not be able to paint a holistic picture of who the customers are. The qualitative methods of gathering information we listed above will call upon the knowledge of Customer Service, Sales, Marketing, Product Managers, Researchers etc. This is very much a team exercise.

Example: Online Stationary Retailer

If we took an example of an online stationery retailer, it would be simple to identify two broad potential customer personas:

End Consumer — customers purchasing for themselves online

Wholesale Accounts — wholesale buyers purchasing on behalf of businesses that will stock the stationery in their own retail stores (online or flagship)

We can see from the ‘personas’ listed above that we have a vague idea about their roles in the purchasing cycle, but that’s about the extent of it. We need to build on these personas to humanise them, and get a better understanding of their holistic relationship with our product.

2. Look Towards Analytics and Layer Results

Now that we’ve established at least a few customer personas, it’s time to flesh them out with qualitative and quantitative data.

So where can we find/gather this information?

• Google Analytics Audience Reports
• Facebook Insights
• Social Media Listening Tools e.g. Hootsuite, Tweetdeck etc.
• Customer Surveys & Polls
• Industry/Market Reports
• Customer Interviews/Support & Feature Requests (note: you should have a streamlined way of capturing and sharing this information with your team)
• In-Product Analytics

After looking through all of this information, trying to answer some of the discovery questions we mentioned earlier, you’ll need to look for commonality between datasets. Think of it this way:

The customer personas you and your team were able to broadly define are attached to funnels. Once you and your team find commonality in data sets, feed this information down the funnel of the customer persona it relates to (perhaps this is a completely new customer persona that you and your team didn’t know that you had).

By the end of the exercise, you and your team should have a pretty good idea of who your customers are, and how to best service them, communicate with them, build solutions for them etc.

Once these personas have been developed, they should live somewhere where the whole team can see them.

Don’t be afraid to sit at your desk and think “What would Sam the System Administrator think about this new feature? Would she use it? How would she communicate its benefits to her team? What are some of the problems Sam may encounter on first use?” etc.

Easy Agile Personas for Jira

Interested in capturing your customer personas alongside your backlog in Jira?

Try Easy Agile Personas for Jira free from the Atlassian Marketplace.

Need help getting started with Easy Agile Personas? Check out our documentation, or get in touch with one of the Easy Agile Partners.

Whether you’re a marketer, a salesperson, a product manager, or even a developer, your work comes back to one thing: the customer.

When you understand who they are, what they want, how they talk, and how they get things done, you can make better products and promote them in the right way to the right people.

One of the most powerful ways to understand your customer better is to create buyer personas. That’s why we’ve put together a comprehensive guide that includes everything you need to know to create, refine, and use your buyer personas.

What are buyer personas?

Buyer personas lay out the typical characteristics of someone who is likely to buy your products - usually on a single page.

Personas aren’t profiles of real people. You shouldn’t use real names, photos, or personal information on your buyer personas. But they should reflect the general behavior and goals of your real customers

You might create a buyer persona for your ideal customer, or several types of ideal customers that regularly buy your product or service. For example, at Easy Agile, we have personas for the most common roles/titles of our ideal customers, like:

• Release Train Engineer
• Product Manager
• Product Owner
• Scrum Master
• Developer

You might also create anti-personas for the types of customers you don’t want to attract.

What are some other names for buyer personas?

You might know “buyer personas” by a different name, depending on your industry, department, or how you plan to use the persona. For example:

• User persona (if your product is software and your user is also the buyer)
• Audience persona
• Customer persona
• Buyer avatar
• Customer avatar
• Ideal audience avatar
• Buyer profile

While there are some slight differences between some of these names and how they're used in marketing or product management, they are often used interchangeably with "buyer persona".

What are buyer personas used for?

Buyer personas can be used in just about any role or department.

The main purpose of buyer personas is to gain a deeper understanding of your customers. This will help you:

• Improve targeting and reach
• Increase conversions
• Increase ROI and profitability
• Communicate more effectively
• Identify pain points
• Create products that solve problems
• Improve the user experience
• Improve customer loyalty
• Offer the best value to your best customers
• Help the customers who need your product or service the most

Why create buyer personas?

It’s clear that buyer personas are useful for a lot of different things. But let’s take a closer look at the top 6 benefits.

1. Increase revenue

One case study found ROI increased by 124% by using personas as part of a marketing strategy. Another case study found that personas have the potential to significantly increase time spent on a website and could boost marketing revenue by 171%. This makes sense when you consider that the insights from personas can allow you to use your marketing budget to better target and convert customers.

2. Make good decisions fast

Whether you’re a marketer, salesperson, or product manager, you won’t always have time to run a proper analysis, get consensus from your team, or survey your audience before you make a decision. Fortunately, with a clear picture of your audience always at your fingertips, you can make snap decisions with confidence. Buyer personas allow you to anticipate how a feature or change will impact the buyer (and therefore your conversions, retention, and bottomline) by seeing things from their perspective (goals, objectives, fears, and motivations).

3. Understand how people buy

Buyer personas can help you map out the customer journey, showing how your audience goes from the first point of contact with your brand to purchasing your product. Personas can reveal what issues matter to them, what content they’d like to consume, what platforms they prefer to consume it on, and what products they’re most likely to invest in first. When you understand how people prefer to buy from you, you can make this more streamlined by:

• Creating different funnels for different personas
• Showing people the right thing at the right time
• Tackling objections with your content
• Focusing on the most effective channels for your audience

4. Talk directly to your ideal audience

With clearly defined buyer personas, your team will have the data needed to target ads directly to your ideal audience. Not only that, but they’ll be able to use ad creative that talks to your audience pain points and uses language that they can understand. In turn, this should lead to more clicks, more conversions, and more customers that are the ideal fit for your product.

5. Be more consistent

Buyer personas can help your whole team get on the same page about who your customers are and how to target them. This can help you deliver more consistent messaging and support for customers, which will help build customers’ trust, confidence, and loyalty.

6. Stay focused on the customer

One of the top benefits of using buyer personas is that they help keep your team focused on what’s important: the customer. With so much data available these days, it can be easy to get lost in the numbers. And it’s just as easy to go down rabbit holes, chasing features you want to work on without fully considering what’s best for the customer. With customer personas, it’s much easier to remember that real people buy your product - and that your job is to deliver value to them above all else.

How to research your buyer personas

Don’t assume you know everything there is to know about your audience - real data should inform your buyer personas. Here are some ways you can research your buyer personas:

Survey customers

Customer surveys are one of the most powerful ways to gather data. You can create online surveys through tools like SurveyMonkey or Google Forms, then send these to your existing customers or prospects. Use these surveys to ask questions about audience demographics, habits, goals, challenges, fears, objections, platforms, technology, and preferences. This data will directly inform each section of your buyer persona, so make sure you ask questions that are most relevant to understanding your buyer and how they might find, purchase, or use your product.

Interview key customers

One-on-one customer interviews or focus groups are another powerful way to learn about your audience. Unlike an online survey, this format is more flexible. You could start with some questions to help start a discussion, and then dig further based on the answers that come up. It does, however, require more of a time commitment from you and your customers, so be sure to offer a fair incentive.

Review your database

If you already have a list of current or previous customers stored in your database, they can be a really valuable source of information. Look through the list and see what trends and categories emerge. For example, you might find buyers from small, medium, and large companies. Or you might find that most of your customers fit into one of 3-4 departments or roles, like marketing, sales, and project management. Once you can categorize your customer list, you’ll be able to see how different customer types use your product, consume your content, and other useful insights.

Check your analytics

Analytics can be a goldmine for researching your customers. You likely have access to analytics from your product, any social media pages, and your Google analytics. This data can reveal demographic information, typical usage patterns, preferred devices, preferred social media channels for different audience groups, what they search for, and more.

Do social listening

Social listening means monitoring your social media channels to see what your audience is saying. You might uncover valuable feedback, pain points, objections, and topics that your audience is interested in. You could also find this information by looking at competitors’ channels, searching for industry keywords, and even looking at online forums. Sometimes the best way to get to know your audience is when they’re asking for help or recommendations from their peers.

Talk to your team

Finally, ask your team members to share their audience insights. Especially those that regularly talk to customers, like salespeople and customer support. They’re probably familiar with the types of people who buy your product, their biggest challenges, and the questions they need answers to.

A simple buyer persona template

You don’t have to start your buyer personas from scratch. Most buyer personas follow roughly the same format, so find a buyer persona template that fits your needs and goals and start with that. Use the data you’ve collected from your research to fill out a profile for each of your ideal customers.

Let’s go through the above sections on your buyer persona template.

Title and name

The persona title helps you identify the buyer group you’re referring to. Depending on your product, this might be their industry, demographic, job title, aspiration, or something else that helps differentiate them from your other buyer groups.

But sometimes a title isn’t enough. Naming your buyer persona and giving them a photo helps to humanize your buyers. It can help you remember that while the profile is fictional, real people buy and use your products.

Bio

A short bio can help to tell your buyer’s story, summarizing their personality, fears, challenges, and their main goals. While you’ll have all these details listed elsewhere on the buyer persona, putting it in story form can also help to humanize your buyer and make this information more meaningful and memorable.

Personality

The personality section is usually based on one of the popular personality tests, like Myer Briggs, DISC, or Enneagram. This can be helpful to understand tendencies like introversion vs extraversion, decision making styles, and how much information your buyer is likely to need when choosing or using your product.

Motivations and goals

Under motivations, list the things that help move your buyers onto the next step in the buying process. You might include things like fears and goals, but also external triggers like ideas and anything that might help them trust your brand or product.

Your buyers’ goals or objectives might include their bigger vision for their career or life, but also the smaller goals that they want to accomplish by interacting with your brand or buying your product.

Challenges

Challenges should summarize any problems your buyer is experiencing that relate to your product - or the reason they might buy your product. You could also touch on fears and pain points, or create a separate section for these.

Tools and technology

Tools and technology are especially useful if your buyer needs specific skills or integrations to effectively use your product. Or it might just reveal how they prefer to communicate - whether via social media, email, or phone.

You can, of course, add other sections to your buyer persona. It all depends on how much information you need to get a clear understanding of your customer, target them, and have meaningful conversations with them. At the same time, keeping your persona short (a single page is ideal) and straight to the point will make it easier for your team to use.

How many buyer personas should you create?

Most organizations will need around 3-4 personas to cover most of their audience groups. But the right number of buyer personas will depend on how diverse your audience is.

The main point here is that your buyer personas shouldn’t cover every possible buyer - only your ideal prospects. Consider the 80/20 rule - it’s likely that 20% of your customers are responsible for 80% of your sales, so don’t be afraid to prioritize the 20%. Including personas that aren’t ideal customers will take the focus away from those that are.

Tip: If you’re struggling to categorize your audience into groups and narrow down your buyer personas, try a card sorting exercise. Create mini profiles for all your audience types on separate cards and then eliminate the audiences that aren’t profitable or ideal customers. Then group the remaining profiles together based on similar demographics, challenges, and goals. When you can’t easily combine any more cards to make groups, stop the exercise. These are your buyer personas.

Start using your buyer personas

Buyer personas are incredibly versatile - any part of your business that interacts with customers or impacts them can benefit from using buyer personas. So, don’t leave them sitting in a folder somewhere… start incorporating them into your teams’ processes right away.

Now that you know just about everything there is to know about buyer personas… now’s the time to create yours and (most importantly) incorporate them into your processes so that you can reach more of your best customers and build a better product for them.

Get a headstart with Easy Agile Personas for Jira

If you use Jira, you can add your buyer personas inside the platform by following this step-by-step guide. Sign up with Easy Agile Personas for Jira and link your personas to issues in your backlog and story map.

In the meantime, we’ve got more articles you might want to check out, like:

And tag us on Twitter @EasyAgile if you’d like to share how your teams create buyer personas and build them into your processes!

There are some things so obvious that you wonder why it hasn’t happened sooner or how you ever lived without it. This is how we feel about our just-launched integration between Easy Agile User Story Maps and Easy Agile Personas.

Central to successful user story mapping are the questions:

1. Why are we building this?
2. Who are we building this for?
3. What value will the solution provide for the customer and when?

The answer to all of these questions and the raison d'être for a user story map in the first place is the user or customer.

User story mapping is the visual representation of the journey a customer takes with a product - helping you and your team to focus on what provides the most value to your customers and their desired outcomes.

A user persona or customer persona is the embodiment of the characteristics and behaviours belonging to your most valuable customers. It helps everyone in your team have a shared understanding of who your customer is in order to empathise with them and have them front of mind when working on ways to improve the product.

5 ways adding Personas takes your User Story Map to the next level

So what's the result of bringing these two powerful agile tools and practices together (apart from the latest version of Easy Agile User Story Maps and Easy Agile Personas)?

Without going into the benefit of user story mapping or creating user personas as separate practices, here are five key benefits you’ll gain from adding your user Personas to your User Story Map.

1. Add the most important context to your User Story Map - your user

How many times can you honestly say you’ve written or worked on a user story without really knowing who that user is? Could you confidently share their interests, motivations, communication styles? Could your teammates?

We know companies like yours want to be more focused on their customers, and the truth is you can’t afford not to. According to a Walker study, customer experience will overtake price and product as the brand differentiator by the end of 2020.

We also know it’s easier to work on the things we like to work on, or what’s next on the to-do list, or the problems we identify as important - but are these the things that are most important to your most valuable customers?

The integration between Easy Agile Personas and Easy Agile User Story Maps adds the most important context to your User Story Map - your user - helping your team keep them front of mind.

Easy Agile Personas allows you to link stories on your backlog to Persona profiles in the Jira issue view, using the Persona and Persona Importance fields. In the latest version of Easy Agile User Story maps, we’ve exposed these fields in the issue view modal. This means that no user story will be left behind because you can now connect it with a user right there on the issue in your Story Map.

NB: The Persona and Persona Importance custom fields must be on the screen used by your Project before they will appear in the issue view in Easy Agile User Story Maps. Not sure how? Read this doc which explains how to do this.

2. Prioritise the work that delivers better value to your customers

In addition to the Persona custom field on the issue view, you can also set Persona Importance for your Issue. This enables your team to focus on what provides the most value to your customers and their desired outcomes and prioritise work accordingly. Focussing your team on work that delivers better value to your customers starts by determining what that work is in practical and tangible terms i.e. your issues in Jira.

3. Gain a holistic view of the journey for each Persona

So now that you’re able to add the context of your customer and how important your work is to them, we thought it was also important to be able to filter your story map by Persona and Importance to Persona with a native filter. Prior to this, the only way to filter the Story Map by Persona was to manually create a quick filter outside of the Story Map, for each of your Personas.

By filtering your board by Persona, your team has a holistic view of the customer journey and can quickly and easily see which developments in the upcoming Sprint/Release directly impacts and serves each of your Personas.

4. Better visibility to easily align your team's output with customer outcomes

Together with the custom fields on your issue and native Persona filter, the ability to filter your board by Importance to Persona allows for better visibility and enables greater and more effective collaboration between teams. Not only does this make it easier to ensure that high importance, low effort stories are being prioritised, but also unleashes your team’s capability to run truly customer-focused story mapping sessions.

5. Seamless planning sessions with less interruptions

With Easy Agile Personas and Easy Agile User Story Maps, not only do you not need to leave Jira to create your Personas or map out your User Story, but with this integration you don’t even need to leave your Story Map to assign issues to Personas and Persona Importance. We’ve worked hard to have Easy Agile Personas and Easy Agile User Story Maps work better together - so your team can too.

Ready to add Easy Agile Personas to your Story Map?

Start your free trial

Not yet a User Story Map customer? You can try that for free too.

A user story map is a collaborative practice that guides an agile team in the creation of their product backlog.

The story map captures the journey a customer takes with the product including activities and tasks they undertake.

Creating the story map as a team ensures team members are on the same page from the start of development through to ongoing delivery of new releases.

In this post we’ll explore the aspects of a successful story map.

Backbone

A backbone provides structure. The backbone of the user story map captures the high level activities a user will accomplish while using the product.

If we take a simple example, buying and watching a movie on an Apple TV, we may have the following activities:

• select movie
• purchase movie
• watch movie
• review / recommend movie

For a user to watch a movie on the Apple TV they would have to complete three of these activities. And there may be other follow up activities such as writing a review or recommending the movie to a friend which we want to encourage.

Chronological Order

Once we’ve got the activities of the backbone identified we will order them in the chronological order of how a user will interact with the product. Following on with the Apple TV example we will make sure the order is correct:

It is common to rearrange existing activities or add new activities as the discussion unfolds. This is a key benefit of the collaborative approach to building the product backlog as we have the shared wisdom of an entire team involved in the discussion.

Stories

Below each activity on the backbone we create user stories which flesh out the customer journey. For example, below the ‘select movie’ activity we may see stories for:

• free text search
• browse by genre
• browse by recent addition
• browse by most popular
• browse by most popular by genre
• browse by recent addition by genre

These stories are ordered by value to the user. Value may be identified through conversations with users, analytics on usage patterns, or another form of insight appropriate for your product.

Sequence

Once the team has the backbone and stories ordered it is time to sequence the work. What do we want to deliver in our MVP, our 1.0, 2.0, etc.

We split the story map horizontally to show what is in and out of each release.

We can then begin delivery, and as we deliver releases we can track our progress against the story map. Product Managers will often start a sprint planning session by reviewing the story map to ensure that all team members are still on the same page.

User story maps turn a flat backlog into a vivid representation of the customers journey.

A few final tips:

Keep the story map up to date as work progresses so stakeholders can visualise progress in real time;

Use the story map to communicate the roadmap with customers and share the product vision.

User story mapping is an essential practice for every agile team. They are an excellent technique for ensuring the team understands their customers, can clearly articulate the solution and stays focused on delivery.

At Easy Agile we’re converts to the practice of story mapping. In fact we’re so passionate about user story mapping that we created a JIRA add-on that assists teams with conducting sessions. Try Easy Agile TeamRhythm today.

Story points in agile is a microcosm of agile development itself — working together as a team to estimate scope develops an atmosphere of collaboration, shared understanding, and continuous improvement. Agile story points can also provide clarity in a user story map by providing insights into how much effort you're planning to allocate to developing each part of your customer's journey through your product.

Story points are effort estimators. They’re an alternative to traditional estimation techniques that measure the expected effort of a project in days, weeks, or months. With agile story points, instead of asking, "How long will this project take?" we use relative estimates about the effort it might take to complete each item in the backlog. For example, an item that is assigned two story points is expected to be twice the effort as an item estimated as one point.

So, why should agile teams use story points? Let's see how story point estimation, sprint retrospectives, and velocity metrics all build consensus and allow team members a clear vision into the prioritization of your product backlog.

Story point estimation for the whole team 🙌

In sprint planning, product and engineering teams work in tandem to gain a shared understanding of the effort required to complete backlog items. During planning, the team agrees to a story point estimate for each user story in the sprint.

Point estimation is a practice in collaboration and consensus-building among team members. The team as a whole participates in determining the point value for each item in the sprint. By discussing each other's perspective on the estimates:

• Product owners better understand developers’ reasoning for their estimates.
• Developers gain empathy for the product owner's need to assess tradeoffs and make prioritization decisions from sprint to sprint.
• QA testers have an opportunity to weigh in on the complexity and risk of the work being estimated and the amount of work needed to create and run tests.

One common methodology for employing agile story points is to assign values to backlog items using the Fibonacci sequence — 1, 2, 3, 5, 8, 13, 21...you get it. Mike Cohn provides a succinct reason for this approach — numbers that are too close to each other are difficult to differentiate. This sequence of points provides a much better jumping-off point for your team to discuss the relative effort of backlog items than a liner point system (i.e., 1, 2, 3, 4, 5...you still get it).

By planning with agile story points, you avoid the temptation to place artificial deadlines on sprint items. It's also easier to reach a consensus on the relative scope of items compared to attempting to place a timeframe on each item. You'll spend less time planning and more time working on your sprint!

Estimates are...estimates

Guess what? Your estimates don't need to be perfect! The process of agile estimation is difficult but provides software development teams an opportunity to feel comfortable with story point estimates being just accurate enough to continuously develop. Over time, you will learn from each other and will improve at creating better estimates.

Unpredictability exists in every project. By using rough estimates that are relative to each other, you avoid the trap of overplanning and allow developers to get to work. Story point estimates allow teams to build smooth planning cadences and move seamlessly from one sprint to the next.

Sprint velocity and other key metrics 📈

Agile story points enable another valuable tool for teams to continuously improve their estimation process — metrics. Several metrics can be used in the context of story points and estimation, but we'll focus on two of the most popular ones — burndown and velocity.

Sprint burndown

In any sprint iteration, the team commits to the amount of work that they believe they can complete in that timeframe. A burndown chart visualizes how the team is progressing relative to its commitment over the course of the sprint.

The y-axis is the number of points in the sprint, and the x-axis displays time in the sprint. There are two lines in the chart. The ideal work remaining line connects the start date of the sprint to its end date (it crosses the x-axis to indicate all of the sprint's work is done). The actual work remaining line shows what still needs to be done. The overall idea is for this line to track the ideal line as closely as possible, meaning your estimates are sound and you are completing the sprint's work at a nice pace.

When reviewing this chart, you’ll find common problems facing agile teams. Here are some examples:

• Over- or under-committing to an amount of work
• Adding points to the sprint after it's already started
• Erratic movement in the actual work remaining line
• Overcommitments that force user stories into the next sprint

Burndown is closely related to velocity, which measures your team's pace of work.

Sprint velocity

A development team's velocity is the amount of work that is completed in each sprint. It can be used as a measure of how long it will take the team to work through its backlog. Because agile story points are as a relative estimation, teams can use them as a baseline to understand how their velocity evolves.

Here, we see a representation of a team's velocity over the course of several sprints.

Sprint retrospectives are an opportunity to discuss any issues made apparent by the sprint's burndown or the team's velocity. It's a time to reflect as a team, review your metrics, and figure out if there are opportunities to refine your process and improve together.

Here are some questions to ask during this process:

• Should we adjust our expectations of getting through the backlog?
• Do we need to tweak our estimation process?
• Should we consider adding a team member?
• Are we over- or under-committing to the amount of work in our sprints?

While these metrics provide insight into your estimation process and your team's pace of getting through your backlog, putting your items into a user story map provides another layer of context on your overall prioritization decisions.

User story mapping with agile story points

Story points are not only important in the context of sprints. Placing them in user story maps produces a visual of strategic product prioritization.

User story mapping in a nutshell 🥜

A user story map takes the items in your flat backlog and places them in the context of your user journey through your product. It's a view of all of the actions your customers take from sign-up to log-out and every major action they take in-between. Instead of having a straight list of items (backlog), the user story map organizes them by your customer's workflow.

For a more comprehensive view of this method, read our ultimate guide to user story maps.

Unflatten your Jira backlog with user story maps

With Easy Agile User Story Maps for Jira, you can see the number of agile story points assigned to each stage of your users' story map. Seeing point estimations in your customer’s journey provides product teams and stakeholders a user-focused view of prioritization.

This can help answer questions such as:

• Are we investing too much effort into one part of the journey?
• Should we smooth out the allocation of points across the journey or focus on one key problem area?
• Will the next release provide enough added value to our customers at a certain stage in their product journey?

It also provides another chance for your team to collaborate! By reviewing your story map together, you're sure to come up with more insights and iterate on your prioritization decisions.

Agile story points, combined with user story mapping, is an effective way to bring teams together to create an agreed-upon view of prioritization across a customer’s journey.

How do you feel when someone mentions “planning”? Do you look forward to the opportunity or does the thought of making a plan send you running for the hills?

Sprint planning is a crucial part of the agile sprint cycle. It helps you and your team align around common goals, and sets you up for a successful sprint. Even if planning isn’t one of your strengths, the good news is that you can practice and get better over time with the help of some good advice.

We’ve combined our best sprint planning tips into an ultimate guide to agile sprint planning, with everything you need to run efficient and effective planning meetings.

What is agile sprint planning?

Agile sprint planning is a key ceremony in the agile sprint cycle. It signifies and prepares the team for the start of the sprint. Without this planning, there is a very real risk that the team would lack focus and fail to align on what is most important.

Effective agile sprint planning has three key parts; a sprint goal, an understanding of team capacity, and a prioritized set of backlog items. Each element depends on the other for success.

The idea is to align your team around a goal for the next sprint by agreeing on a set of backlog items that are achievable within the sprint and contribute to reaching the sprint goal. Gaining focus and clarity on what you plan to achieve will help your team to work better together and to deliver on objectives.

It is best to start with an agreed sprint goal. You can then prioritize work on the specific set of backlog items that your team has the capacity to complete, and that will contribute to making your sprint goal a reality.

How sprint planning fits within the Scrum process

We’re big fans of the Scrum process, and it’s hugely popular with many software development teams. While agile sprint planning can take many forms within the different agile methodologies, for the purposes of this guide, we’ll focus on agile sprint planning within the Scrum framework.

If your team doesn’t follow Scrum don’t worry — you’ll still find value in our preparation tips, meeting guide, mistakes to avoid, and sprint planning resources.

💡 Learn more: What's the Difference Between Kanban vs. Scrum?

Scrum roles: The people

There are three main roles within a Scrum team.

1. Product Owner
2. Scrum Master
3. Development team

The Product Owner puts in the work upfront. They help prioritize the product backlog items and decide which should move to the sprint backlog. These important decisions guide the goals of the sprint and determine the tasks the team will tackle over the next sprint.

The Scrum Master acts as a guide, they lead meetings that help ensure that the Scrum framework is followed throughout the sprint to keep the team on track. The Scrum Master helps the team get the most out of the entire Scrum process and each individual Scrum ceremony.

The development team is made up of the various people who will complete the work agreed upon during sprint planning.

There are others that you might refer to during sprint planning, such as stakeholders, users, and customers. While these aren’t technically Scrum roles, they play a critical role in product development. Stakeholders should be brought into the process early and often, and customers should always be top-of-mind when making any development decisions. Some teams find User Personas to be a valuable way of keeping user value in focus.

Artifacts: What gets done

Artifacts are the things to get done — different breakdowns of what the team hopes to accomplish:

1. Product backlog
2. Sprint backlog
3. Increments

Product backlog items are the tasks the team believes they need to accomplish in order to complete a product or specific improvement of a product. It is the big master list of everything that the team thinks they need to accomplish. The product backlog is flexible and iterative, and it will evolve as the team learns more about the product, stakeholder feedback, and customer needs.

The sprint backlog is more focused than the product backlog. The product owner moves the most important backlog items from the product backlog to the sprint backlog at the beginning of each sprint based on current issues, priorities, and customer needs. The team aims to complete all of the sprint backlog items over the course of the sprint.

An increment is a concrete stepping stone toward reaching the Product Goal. An increment must be verified as usable in order to provide value, which means that any work completed cannot be considered part of an increment unless it meets the Definition of Done (an agreement among the team of what “done” means). This is a formal description of the state of the increment when it meets the quality standards required of a product. Once the work completed satisfies the agreed Definition of Done, you gain an increment.

Scrum ceremonies: Where Sprint Planning fits

There are a number of ceremonies in Scrum that occur each sprint. This is where sprint planning fits within the Scrum process.

1. Sprint planning
2. Daily scrum (or standup)
3. Sprint review
4. Sprint retrospective

💡 Learn more: Agile Ceremonies: Your Guide to the Four Stages

Sprint planning is the first Scrum ceremony — it prepares the team for the sprint. The planning session sets everything into motion, aligning the team on what’s most important for this sprint. This is when decisions are made and key backlog items are moved from the product backlog to the sprint backlog.

The second ceremony repeats every day of the sprint. Daily standups bring the team together to discuss progress and blockers that might be getting in the way. By getting the concerns out in the open early, the team can avoid the frustration of delays and ensure work continues to flow.

The final two ceremonies happen at the end of the sprint. For the sprint review, the team comes together to determine the success of the sprint based on the “Done” work completed. It’s also a chance to bring in stakeholders to gather feedback on what's been accomplished so far. The sprint review ensures customer insights are always top-of-mind, stakeholders continually see progress, and guarantees the product never strays too far from what the stakeholders are looking for.

The sprint retrospective gathers critical insights from team members about how the sprint went. What went well, what didn’t go so well, and what could be improved upon for next time? These valuable insights are what makes Scrum agile — the team is always thinking critically about the process and looking for ways to improve the work and how they work together.

We’ll talk about these ceremonies in more detail below when we discuss what happens after the sprint planning meeting.

The benefits of agile sprint planning

Agile sprint planning is a powerful meeting that should not be overlooked or underestimated. It is an opportunity to:

• Bring the whole team together and align around common goals
• Set context by starting the sprint with clear priorities
• Identify potential roadblocks before they occur
• Bring stakeholder feedback into the planning process
• Learn from previous sprints by considering sprint review and retrospective insights
• Consider team capacity and adjust accordingly to ensure that goals are achievable and that the team isn’t overcommitted in the upcoming sprint
• Account and plan for dependencies that may impact the flow of work.

How to prepare for a sprint planning meeting

We know we said that a sprint begins with sprint planning, but there are actually a few important steps you must take in order to prepare for the planning session. Unfortunately, you do need to do a little planning for the planning meeting.

Backlog refinement

Backlog grooming or refinement keeps your backlog healthy, up-to-date, and ready for sprint planning. A refined backlog will help ensure your team’s planning time is used efficiently and effectively since you won't have to waste time adding details to the backlog that could have been completed in advance before everyone came together.

The product manager should groom the backlog a few days before the sprint planning meeting to make sure it’s ready.

Tips for maintaining a healthy backlog:

• Ensure stories are in order of priority
• Prioritize items that bring the customer the most value
• Add detail to the highest-priority backlog items
• Split any user stories that are too big
• Delete any user stories that aren’t relevant anymore
• Create new user stories based on new or clearer needs
• Add items based on new stakeholder feedback
• Make adjustments based on bug fixes
• Assign more accurate estimates

💡 Learn more: Essential Checklist for Effective Backlog Refinement (and What To Avoid)

Be consistent

A consistent meeting time that’s scheduled well in advance will ensure that the entire Scrum team keeps the time slot open. Book your sprint planning meeting on the same day and at the same time every sprint so that no one forgets or double books.

Sprint planning is not a meeting to be shuffled around, delayed, or ignored — sprint planning meetings are essential to the success of every sprint. Ask your team about a specific, recurring time to meet, and ensure it works for everyone.

How to run a sprint planning meeting

While the agile method is flexible and collaborative, it isn’t chaotic; everything needs to begin with a plan.

1. Stick to a set sprint planning meeting duration

As with any kind of meeting, the team can be easily sidetracked without a timebox. After all, talking about the work that needs to be completed is often easier than actually completing it. It’s the Scrum Master’s job to keep the team on track and make sure the time limit isn’t exceeded.

Go into the sprint planning meeting well-prepared; a clear agenda and a well-refined backlog mean your team can get straight to planning.

Set a realistic timebox for the meeting and stick to it. We recommend that you avoid scheduling more than 2-3 hours for a sprint planning meeting, but as you become more skilled in sprint planning, you’ll better understand the length of time that works for you and your team.

2. Use estimates to make realistic decisions

You want your team to be as productive as possible, but overloading them can actually hinder productivity and focus. Unreasonable expectations are demotivating and overcommitted team members are more likely to make mistakes.

You need to understand the effort and time it will take to complete the goals you set out to accomplish for each sprint. Agile estimation techniques and story points provide a better understanding of team capacity, individual capacity, and what a reasonable workload looks like. Reasonable and realistic goals will help your team stay motivated and support a consistent flow of work.

3. Define clear goals and outcomes

What does the team aim to accomplish between now and the end of the sprint? Set clearly defined goals and outcomes that everyone understands. Do your goals align with what you learned from past sprints? Do they align with customer needs? Does everyone agree on what the next sprint will (roughly) look like?

Don’t assume that everyone is on the same page. Ask questions and encourage your team to speak up if anything is unclear. It’s better to clear up discrepancies or misunderstandings now rather than once the work begins.

Post your sprint goal somewhere that is easily accessible so that the team can refer back to it throughout the sprint.

💡 Learn more: How to Make the Most of Your Sprint Goals

4. Decide what it means to be ‘done’

What does “done” mean for any given backlog item, increment, product issue, or product as a whole? The team and your stakeholders need to agree on what done looks like in order to set realistic goals that meet the expectations of everyone involved.

As you set goals and choose which backlog items to complete for the next sprint, be clear about what it means to meet and complete the goals you want to accomplish.

5. Align sprint goals with product goals

Sprint goals should always align with your broader product goals. Your sprint may take a specific direction depending on current product issues, bug fixes, or customer concerns, but it’s important to keep an eye on the big picture.

Choose backlog items with care — make sure they relate to the larger product goal and that each works in sync to move development forward. Overlooking product goals in sprint planning could mean that each sprint looks more like a random selection of to-do lists that don’t connect back to customer needs, relate to product goals, or help you reach important increments. The result will feel like a lack of progress, which risks disengaging the team and other important stakeholders, like your users.

What happens next?

Now that the planning is done, you’re ready to implement your plan and complete the work. But that doesn’t mean that team members go off and work in isolation.

Daily scrum (or stand-up)

The daily scrum or stand-up is an opportunity for a collaborative agile team to maintain progress. It should be a quick check-in at the start of each day.

The team will discuss what has been done in the past 24 hours, any roadblocks they might have hit, and what the team hopes to accomplish the next day.

This critical check-in helps the team stay on the same page, helps to ensure the continued flow of work, and keeps the team on track to achieve sprint goals.

Sprint review

A sprint review meeting takes place at the end of a sprint. It's a chance for the team to review all of the “Done” issues for that period. The sprint review determines whether or not the goal for the sprint was achieved.

It’s a chance to demonstrate shippable working product increments to the team, and also an opportunity to bring in stakeholder feedback. This feedback gives you valuable insights to assess if you’re on the right track, or need to make changes in the next sprint. The sprint review is also excellent preparation for the next backlog grooming and sprint planning session.

💡 Learn more: Introduction to Sprint Reviews

Sprint retrospective

While the sprint review looks at what was accomplished and how to move forward, the retrospective examines your processes and how the team is working together.

What did you learn during the previous sprint? While retrospectives can take many forms, the goal is to discover what worked well, what didn't go so well, and what could be improved upon next time. Your team will use the insights gathered in the retrospective to improve how you work together and deliver value to customers in the future.

💡 Learn more: 5 Steps to Holding Effective Sprint Retrospectives

Agile sprint planning mistakes

It’s easy to fall into bad habits, especially as deadlines and product launch dates approach. Avoid these common agile planning mistakes to ensure your team is always making the most of the agile methodology and the Scrum process.

Unrealistic expectations

Choosing unattainable goals sets your whole team up for failure. Failing to meet your sprint goals sprint after sprint is damaging for team motivation and morale.

Use estimates to set reasonable goals as best you can. Consider team capacity, factoring in your past knowledge of how long tasks take to complete, how the team works, and potential roadblocks that could arise along the way.

Lack of context

Your team will benefit from an understanding of how the issues they’re working on fit into the bigger picture.

Depending on the tool you’re using to plan and manage your work, it can be difficult to see the contextual detail needed to plan and work with clarity. The more items you have, the more difficult and overwhelming it will be to organize and prioritize. Use tools that allow you to add context, depth, and customer insights with clean functionality to adapt your plan to the needs of your team and stakeholders.

Neglecting your backlog

We mentioned this point when we talked about what you need to do to prepare for sprint planning. It’s worth mentioning again because it’s a common mistake.

When you go into a sprint planning meeting without a well-managed backlog, you lack the clarity you need to plan effectively. Your time is valuable, and so is the time of your team, so it should be treated with care and used effectively.

A well-managed backlog is DEEP:

• Detailed appropriately
• Estimated
• Emergent
• Prioritized

💡 Learn more: The 4 Characteristics of a Good Product Backlog

Not allowing the plan to adapt

When you plan your sprint, you’ll do everything you can to prioritize the most important tasks for the length of the sprint. It’s important to try to stick to the plan as best you can, but you also need to adapt as you acquire new information.

Be ready to make changes on the fly should you hit roadblocks or acquire new information about customer needs, concerns, or product issues.

Failing to understand stakeholders

You need to understand the goals and priorities of stakeholders to be successful. Just because you’re happy with what you’ve accomplished doesn't mean your stakeholders will too.

Ensure your stakeholders are brought into your process early and often and help them understand how you work to provide them value. Gather feedback from stakeholders regularly to ensure your goals are aligned. A good time for this is during the sprint review. Just make sure those insights are transferred over to your next planning meeting.

Not choosing tools with a customer-centric approach

Successful product development delivers what the customer needs and wants. To build for your customers, it helps to use tools for planning and work management that makes it easy to keep them top-of-mind. Incorporating user story maps and customer personas into your planning helps you and your team prioritize the work that will deliver the most value first.

💡 Learn more: 10 tips for more effective user personas

Failing to incorporate retrospective insights into planning

Retrospectives are the best thing you can do to help your team work better together. During a retrospective, you're asking your team to be open and honest about how things went over the course of the sprint so that you can learn from each other.

Failing to learn from those insights means that the collective time spent in the retrospective has been wasted, and the feedback that your team has shared is devalued.

Incorporating the learnings you gain from a retrospective into your next planning session and into the next sprint, will support your team to improve every time, helping them gain work satisfaction and deliver better outcomes.

Virtual vs. in-person sprint planning

The advantages of remote work also bring challenges for collaborative planning. No matter the way your team chooses to meet, whether virtually, in person, or a combination of both, it’s important that you choose tools that meet the needs of your team.

Tips for virtual sprint planning:

• Be really prepared - communicate plans clearly ahead of time, so that everyone has clear expectations.
• Use a video conferencing tool that allows for breakout sessions
• Set up the interactive online resources you plan to use and include links in the meeting request.
• Online discussions don’t start as naturally as they would in person, so share discussion topics ahead of time, and consider preparing some ice-breakers.
• Ensure that you’ve accounted for time differences for teams that span time zones.
• Tech issues arise no matter how much advanced planning and testing you do. Always expect the unexpected.

Tips for in-person sprint planning:

• Book a meeting room with plenty of space for your team, and consider separate spaces for breakout sessions.
• Ensure that your meeting room will accommodate a shared view of your sprint plan - do you need a wall for sticky notes, or a screen to share a digital tool?
• If some of your team members work remotely, it’s difficult to involve them in the same way, so consider how this might work for your team. They won’t be able to read a whiteboard or sticky notes as easily, so a digital solution may be best.
• If you choose to plan your sprint ‘on the wall’, be sure to nominate someone to transcribe your plan into your work management tool at the end of the planning meeting.

No matter where your planning takes place, always remember to prepare your backlog ahead of time so that you can have focused and informed discussions during sprint planning.

Additional agile resources

We’re continually adding to our content library, which is filled with resources, how-to guides, product updates, and more.

📚 Add these to your list:

• Easy Agile Podcast Ep.20: The importance of the Team Retrospective
• Easy Agile Podcast Ep.18 Top qualities of an agile leader and team
• Easy Agile Podcast Ep.16 Enabling high performing agile teams with Adaptavist
• Being agile vs doing agile
• The Ultimate Guide to User Story Mapping
• The Ultimate Guide to Buyer Personas
• The Ultimate Guide to PI Planning [2022 SAFe Edition]

Using Easy Agile to improve sprint planning

Make your sprint planning smooth and effective with Easy Agile TeamRhythm. Transform your flat product backlog into a dynamic, flexible, and visual representation of the work to be done. Seamlessly integrated with Jira, with TeamRhythm you can:

• View your Jira stories, tasks, and bugs in context, aligned beneath their epics on the story map
• Drag and drop Jira issues from the backlog into a sprint
• Create new issues right on the story map
• Estimate issues on the story map, and gauge capacity with story point totals in each sprint swimlane
• Publish the sprint goal on each sprint swimlane, so it’s always top of mind
• Use filters to focus on the stories and issues that are most important now
• Group epics by a third level of hierarchy, to easily see how the work in focus contributes to the bigger picture

Easy Agile TeamRhythm also supports team retrospectives, with flexible and intuitive retrospectives boards created for every sprint. You can add retrospective items right from the sprint swimlane, so you don’t forget any important points. And you can turn retrospective action items into Jira issues that can be scheduled for future sprints, so you’re always getting better at what you do, and delivering for your customers.

Thanks for reading our ultimate agile sprint planning guide! If you have any questions about this guide, our other content, or our products, reach out to our team at any time. We love hearing from you.

We’ll continue to update this guide as we gain more agile planning insights, techniques, tools, and best practices.

Agile planning is a critical phase of the agile process, as it determines the team’s priorities and sets the tone for the work to come. The planning process helps agile software development and other product development teams sort through new information, adapt to roadblocks, and address evolving customer needs.

Agile is an iterative process that helps teams reduce waste and maximize efficiency for the ultimate goal of bringing value to customers. This customer-first approach helps teams make informed choices throughout the development process — choices that continually and consistently provide value to stakeholders.

It’s the opposite of traditional project planning, which takes a step-by-step waterfall approach. For many years, the method dominated project planning with detailed plans laid out at the beginning of a project that had to be adhered to rigidly. This may move a project or product forward, but it neglects to account for any new developments that could occur outside of the “master plan.”

And what about stakeholders? The best part of the agile process is that stakeholders can be brought in at every turn. You don’t need to guess whether or not you’re making the right decisions — you can find out every step of the way by directly including stakeholders in your process. You can adapt your plan as you need to based on what will provide the most value to customers at any time.

Yet, even if you are part of a seasoned agile team, there are still hiccups to overcome and processes to finetune. This post will outline some unproductive agile planning mistakes teams make, including how agile teams can avoid these common pitfalls.

Agile Planning Mistake #1: Not being on the same page as stakeholders

Do you involve stakeholders in your planning process? Do they understand your goals and why you are making each decision? Working directly with stakeholders will help you gain a clear view of what your customers need and want to determine what should be done when.

Never assume you’re on the same page as your stakeholders. They live in a different world than the one you are deeply embedded in, and they may not have the same experience with the agile process, your planning methods, or the agile tools your team uses.

Ensure you never make commitments the team can’t keep. What you thought would provide the most value during the planning phase could be completely different a couple of weeks later.

In order to produce deliverables that meet stakeholder expectations, you need to agree on what those expectations are. Involve your stakeholders in planning, but ensure everyone understands that expectations could evolve throughout the process based on new information gained from successes, failures, and customer responses.

Agile Planning Mistake #2: Using bland, flat product maps

Flat product backlogs are bland and boring 😴. Think carrot cake without icing. They lack the detail and functionality needed to realize the full story of your product backlog.

Plus, once you have more than a handful of items, they become overwhelming and difficult to organize in a meaningful way. It becomes less clear which item is the most important and more difficult to ensure your decisions align with the larger goal of the project.

When you plan out your roadmap, it needs context, and you must be able to clearly see the customer journey. User story maps visualize the customer journey in the planning process and throughout the entire process of product development. They utilize user stories — the smallest unit of work that can bring value to the customer — so you can plan and organize the backlog from the customer’s perspective.

📕 Read our ultimate guide to user story maps to learn more.

Easy Agile TeamRhythm transforms your flat product backlog into an impactful visual tool. Product owners and team members can plan core user activities, manage epics inside the story map, order user stories by priority, and edit story summaries — all while integrating directly with your Jira agile boards.

Agile Planning Mistake #3: Not allowing the plan to live, breathe, and adapt

Agile methodology is an iterative approach. This means your agile planning needs to leave room for changes. Your plan should be able to grow and adapt as you progress with each sprint or product roadmap.

At the beginning of a sprint, you lack the information needed to see the full picture. You don’t have everything you need to build the perfect solution, and that’s okay. It’s all part of the process. Spending hours or days trying to iron out the perfect plan just wastes time that could be better spent learning and solving problems as they come.

You may need to alter your plan after a roadblock comes up in a daily stand-up, or you may learn about a customer concern that completely changes your direction. Iterations are inevitable and welcomed! They help you keep pace with incoming information as you learn from each other, stakeholders, and your customers.

Agile planning isn’t a promise. It’s an outline that will help you reach your goal, and that changes with your goals and circumstances.

Agile Planning Mistake #4: Not incorporating retrospective insights in the following planning session

Retrospectives are an essential piece of the agile process. They give teams a chance to reflect on everything that occurred in an individual sprint or after the completion of a product.

An effective retrospective asks the entire team key questions that can improve the process next time around. What went well? What’s worth repeating again? What didn’t go so well? What could be improved upon next time? What roadblocks or dependencies developed? What did you learn? How did you feel at the end of the sprint?

A retrospective provides insights that will improve efficiency, teamwork and team dynamics, the effectiveness of tools, and communication with stakeholders.

Simply holding a retrospective or collecting retrospective feedback is not enough to gain value. You need to ensure you’re incorporating the feedback into the following sprint planning meeting. The next iteration will be all the better for the time you spend reflecting and improving based upon what you learned.

Agile Planning Mistake #5: Choosing tools that don’t take a customer-centric approach

Whether your team uses a Scrum process, kanban boards, or agile methods, the tools you choose should always be customer-focused. And you need to continue using them in a way that keeps the customer at the forefront of decision making.

Teams can fall into a trap believing they’re focusing on the customer when they aren’t doing much of anything beyond following simple agile methods and generic processes. Customers need to be embedded in your development process right from the planning phase so that every decision a team member makes considers customer needs first.

Choose planning tools that help your entire team get to the heart of what makes your customers tick, and always check in to ensure you are making decisions in line with your customers.

For example, Personas provide a deep understanding of what customers want, need, don’t want, etc. They reveal key information about customer pain points, desires, demographics, goals, shopping patterns, and much more. We highly suggest developing customer Personas to get a rich picture of all the people who will use your product, but it’s not enough to just have Personas lying around.

You need to bring these Personas into your agile planning process and keep them front and center as you complete issues and continue to develop your product.

Easy Agile Personas for Jira helps you create and store Personas within Jira, so you can plan based on customer needs in real-time. The tool will help you empathize with customers in order to make decisions that provide the most value to users at any moment. All of our Easy Agile Jira plugins are customer-focused and designed to keep the customer top-of-mind throughout the product development process.

Learn more on the Easy Agile blog

There’s plenty more where this came from. Easy Agile is dedicated to helping teams work better using agile. We make simple, collaborative, customer-focused plugins for Jira.

We regularly publish lists of tools, advice articles, and how-to guides for agile teams. If you work with Jira, you’ll find our resources are especially helpful in navigating the ins and outs of product development and the Jira plugins that will improve the way your team collaborates.

Agile estimation techniques are amazingly simple yet can sometimes be made more complex than necessary for software development teams. Having experienced the wrath of missing a deadline on previous assignments and fearing 20-hour workdays in the last weeks of a big project, it's no wonder agile team members approach estimation cautiously. How many times has your estimation come back to bite you? 😱

Designed to create a sustainable development pace and provide more realistic deadline expectations for stakeholders, agile estimation techniques use relative sizing rather than predicting real-time estimates.

Popular estimating methods in an agile development environment include story points, dot voting, a bucket system, affinity mapping, and t-shirt sizing. T-shirt sizing is a common agile estimation technique that can be very effective for long-term planning or helping your team get used to relative estimating.

We'll give you a quick review of these agile estimation techniques, but then, we'll dive into t-shirt sizing and the different ways you can use this technique.

Take note of your estimations inside Jira with

Easy Agile User Story Maps

Free Trial

A quick review of some popular agile estimation techniques

If you're reading this article, you're probably already familiar with story points typically used for sprint planning, so we won't spend time rehashing these. However, if story pointing isn't a familiar agile estimation technique, here's an article defining story points and another about specific times when story points might work best on your team.

The other agile estimation techniques we'll review first are more appropriate for road mapping or release planning than sprint planning. Let's run through a quick overview of affinity mapping, bucket systems, and dot voting.

Affinity mapping

In product development, “affinity” refers to similar backlog items, either in terms of types of code, areas of the product, or effort. For affinity mapping within agile estimation, we're talking about grouping work items of similar size. Go figure.

To perform an affinity mapping exercise, the facilitator puts the backlog items on individual sticky notes and attach them to a wall. On another wall, identify one side as "Smaller" and the other side as "Larger." Then, ask the Scrum team to silently move the items from the backlog wall to the sizing wall where they fit based on the item's perceived size, or how long the team will likely take to complete it.

The key to this technique is to move quickly, don't overthink it, and don't discuss it. Once all the items are placed on the wall, team members can discuss which items are potentially sized incorrectly. After a brief discussion, the team can choose whether to move the items.

After everyone is satisfied with the placement, the Product Owner can imagine vertical lines on the wall dividing the backlog into sections and easily assign a t-shirt size to each item and place it on a roadmap.

Bucket systems

A bucket system is similar to affinity mapping, except it expects you to get a little more specific. It uses the numbers 0, 1, 2, 3, 4, 5, 8, 13, 20, 30, 50, 100, and 200 as relative sizes, and team members put all the backlog items in one of the buckets. Again, this is done silently, but the team is free to discuss any items they feel have been placed in the wrong bucket at the end.

Dot voting

Another way agile development teams can estimate is dot voting. Yeah, it's really about putting dot stickers on note cards or sticky notes. But, this is an interesting technique that brings in concepts other than relative size.

During dot voting, team members receive five dots. Those dots relate to what each team member thinks is the most critical work in the backlog. The importance could come from a technical reason like reworking a database to scale before the next busy season or business value like the most requested new functionality from customer feedback.

Backlog items are then added to the roadmap based on value (the number of dots) and then can be sized for effort using another technique.

As you can see, these agile estimation techniques are especially useful if you have a large backlog that makes you feel like you're herding cats every time you try to organize it. Typically, these estimating processes are used at the beginning of a project, significant feature build, or annual or semi-annual roadmap planning.

Now let's take that deep dive into t-shirt sizing.

T-Shirt sizing for product backlog items

Ahhhh, the t-shirt size. XS, S, M, L, XL — how can that be intimidating? It's so simple and yet so flexible. Mostly used for roadmap and release planning, t-shirt sizing is nothing more than a guesstimate at effort based on the information available at the time of the estimate. That's why it's so basic. It's a guesstimate, and that's ok. 👌

You might be wondering why t-shirt sizing is essential if it's such a ballpark figure and relative estimation. It's helpful for long term planning. Yep, you heard it right. Agile teams plan. If you take a quick look at the Agile Manifesto, the fourth value of agile development teams is:

“Responding to change over following a plan.”

A team can't respond to change if they were never following a plan from the start. Long-term agile planning lets you know if you're setting realistic expectations with stakeholders for the next 6 to 12 months. Or if the company's needs change or existing resources won't suffice and you need to spin up an additional team. T-shirt estimates also help determine how many iterations need to be included in each release to deliver the most value to end-users.

Agile estimation starts as a t-shirt size for planning future releases, then is broken down into story points for sprint planning, and can even be broken down further into hours for sprint execution. Regardless, the main point is this: The closer the work gets to a developer's keyboard, the smaller and easier it is to estimate accurately. The t-shirt size is furthest away from execution, so the estimation isn’t expected to be perfect.

T-Shirt sizing is fast

If you've ever inherited a backlog of hundreds of work items and then received the question "How long will it take to finish all that?" you're not alone. Your first attempt to avoid answering that impossible question might be a good backlog cleansing. Let's say you delete any work item over six months old. I mean, hey, if it's been in the product backlog that long, maybe it's not really that important.

But if you've joined a team just getting started with agile methodologies, you'll probably be stuck with a large backlog and product executives expecting an old-fashioned estimate.

T-shirt sizing comes in handy here. Because it's understood that you're delivering gut-level estimations, your team can power through a super-sized backlog in no time. To ensure team members aren't over-thinking each item during t-shirt sizing exercises, restrict decision-making to 30 seconds per item.

The result is a somewhat organized backlog with relative estimates. The product owner and stakeholders can use that information to decide what to move forward within the short term.

How does t-shirt sizing work?

There are a couple of different ways you can tackle t-shirt sizing depending on your backlog size. For a small number of items, planning poker works great — just ask your Scrum Master to swap out the Fibonacci sequence number cards for t-shirt size letters.

This technique also works well if you need to estimate a subset of a more extensive backlog.

You'll probably want to use a process similar to affinity mapping and bucket systems for large backlogs. Everyone works independently to assign sizing and then discusses conflicts at the end. This technique allows even small teams to get through a large backlog relatively quickly.

Finally, some new agile teams might want to start their estimating journey using t-shirt sizes for user stories and sprint planning. Mike Cohn, one of the founders of Scrum Alliance and an authority on agile processes, suggests that if teams go with that approach, they assign a story point value to each t-shirt size. This technique helps teams get comfortable with story points within the safety net of t-shirt size estimating.

Practice makes perfect with agile estimation techniques

Regardless of the type of agile project you're working on or the estimation process you choose, the more you practice, the quicker your team will become master estimators. 👑 We recommend trying a couple of different methods to see which one feels most comfortable for your team.

One last thing, remember that story point estimates are best for sprint planning. Affinity mapping, bucket systems, dot planning, and T-shirt sizing are better for roadmap and release planning.

If you need help moving your planning off the wall and into Jira, you should try

Easy Agile Roadmaps

Don't forget to check out our other blog articles to help your team on their agile journey.

Backlog prioritization is a never-ending task for product owners and product managers. As priorities evolve in response to changing business needs, or even as work is completed, or adjustments to team resourcing are made, it's important to maintain focus on the work that will deliver the most value by keeping your backlog in good shape. Agile estimation techniques can make prioritizing your backlog faster and easier.

So, let's take a look at some specific methods to prioritize your backlog and see how agile estimation can help deliver the most value to your end-users and stakeholders.

5 ways to prioritize a backlog

Of course, there are more than five ways to prioritize work items in a backlog. But, we've picked a few of our favorites that, when combined with an agile estimation process, help keep our product backlog prioritized so we can breeze through sprint planning.

1. Weighted Shortest Job First

Wow, is that a mouthful! Let's use the "WSJF" acronym to refer to this SAFe technique. Not as intimidating as it sounds, WSJF is a simple formula that assigns a business value to product backlog items.

WSJF = Cost of Delay ÷ Job Duration

Cost of Delay is the sum of three relative metrics:

• User/Business Value: the relative importance of the work item.
• Time Criticality: the decline of user/business value over time.
• Risk Reduction: the reduction of business or technical risk.

To determine the relative size for Cost of Delay, think of the lowest business value, the smallest decline in value over time, and the least risk reduction as a 1 value. The same as with Fibonacci sequence story point estimation, adjust that score appropriately when comparing work items to score them relative to one another.

The Job Duration is also expressed in relative terms. If you estimate your work items using relative estimation with story points, the story point value equals the Job Duration.

If you're using this technique to prioritize a large amount of work in a backlog where some items have only been t-shirt sized, convert your t-shirt sizes to standard Fibonacci numbers and use that value.

Warning: Be careful with converting t-shirt sizes to story points. You'll need a way to flag the t-shirt size work items that you converted to story points. You and your Scrum Master need to recognize those as t-shirt level estimations rather than the real story point estimates that come with fully refined work items.

See more at a glance in Easy Agile TeamRhythm, to make prioritizing your backlog faster

💡Tip: Add up to three extra fields on issue cards

SEE HOW

2. MoSCoW

Must-have, should-have, could-have, and won't-have are the buckets used to prioritize a backlog with the MoSCoW technique. The product team defines these designations based on the product's unique features and competitive offerings.

Each work item falls into one of those categories. The easiest part of this process is sending Won't-have items directly to the trash and getting them out of your way. Next, prioritize must-haves first and then should-haves. The could-have items naturally fall to the bottom of the backlog.

Take these items through your regular refinement meetings with your team members, and assign each item a t-shirt size or story point value. You're then ready to add the right amount of work items to your sprints or releases based on your teams' velocity or the number of story points they expect to finish during a sprint.

3. Kano

The Kano model of prioritization uses five classifications:

• Must-be: the basic functionality that your users expect.
• Attractive: a pleasant surprise for your users, but no one is going to be upset if it's not there.
• One-Dimensional: work items that make your users happy and will disappoint them if they aren't part of your product.
• Indifferent: work items that are unimportant to your customers. Often, these work items represent technical debt or enhancements that help the software development team develop more efficiently or work in the latest versions of their tech stack — but your customers really don't care about them.
• Reverse: the process of undoing a previous feature or update. If you've ever built a feature or made a UI update that your users hated, you understand reverse work items. Oops. Unfortunately, sometimes these are necessary evils, especially when it comes to security features or transitioning users to a new product after retiring a legacy product.

Like the MoSCoW method, you'll estimate these work items during refinement and then add them to your iteration or release plan. But, different from MoSCoW, you may want to balance out your sprints and releases with work items from each classification.

4. Stack Ranking

The most brutal of all prioritization techniques, stack ranking forces teams to have a linear rank of work items, which means there is only one top priority, one second priority, one third priority, and so on. Brutal!

Once you get used to it, stack ranking is a useful way to force product managers to make tough choices between work items. Even if two work items can be completed during the same sprint, it's up to the PO to determine which one gets done first, and then that choice is reflected in the sprint backlog.

Often, this job becomes easier when it's put in dire terms. For instance, if you only had one day to attract new users to your product, what work would you want in production? BOOM! There's your top priority.

The nice thing with stack ranking is that it allows POs to slide smaller work items into current sprints when other higher-priority work is too large. Adding the larger work item over-commits the team based on their velocity. Those small work items serve to fill up sprints so teams can maintain velocity and be as productive as possible. So, just because a two-story point work item is two-thirds the way down the backlog doesn't mean it will never get done.

5. Story Mapping

Story mapping helps you visualize the customer's journey through your product from start to finish. (Yep, we stole that straight from our other excellent article on story mapping.) For advanced story mappers, take what you’ve learned about story mapping, and think about how you can add MoSCoW or Kano techniques to your story maps.

Perhaps your epic backbone at the top of the user story map could represent the buckets in the MoSCoW method?

If you're like us, your story mapping sessions are productive brainstorming activities, and you'll leave the sessions with way more work than you can accomplish. By applying MoSCoW or Kano principles to the stories in your user journeys, you’ll discover the most important stories to prioritize and the stories that can wait for a later release.

Building agile estimation into backlog prioritization

We've given you five different techniques to corral your work items into an organized, prioritized, value-delivering product backlog:

1. Weighted Shortest Job First
2. MoSCoW
3. KANO
4. Stack Ranking
5. Story Maps

We've also shown you ways to incorporate agile estimates like t-shirt sizes and story points into your prioritization process to keep your team delivering the most important work while maintaining velocity and dazzling your customers and stakeholders.

We encourage you to take these ideas, share them with your team, and give them a try. If you need help using the Story Map concept, try Easy Agile TeamRhythm. However your team prioritizes its product backlog, remember to put the most important work first and then adjust those priorities as needed. Keep it easy and keep it agile!