The Problem with Agile Estimation
The seventh principle of the Manifesto for Agile Software Development is:
Working software is the primary measure of progress.
Not story points, not velocity, not estimates: working software.
Jason Godesky, Better Programming
Estimation is a common challenge for agile software development teams. The anticipated size and complexity of a task is anything but objective; what is simple for one person may not be for another. Story points have become the go-to measure to estimate the effort involved in completing a task, and are often used to gauge performance. But is there real value in that, and what are the risks of relying too heavily on velocity as a guide?
Agile estimation
As humans, we are generally terrible at accurately measuring big things in units like time, distance, or in this case, complexity. However, we are great at making relative comparisons - we can tell if something is bigger, smaller, or the same size as something else. This is where story points come in. Story points are a way to estimate relative effort for a task. They are not objective and can fluctuate depending on the team's experience and shared reference points. However, the longer a team works together, the more effective they become at relative sizing.
The teams that I coach have all experienced challenges with user story estimation. The historical data tells us that once a story exceeds 5 story-points, the variability in delivery expands. Typically, the more the estimate exceeds 5 points, the more the delivery varies from the estimate.
Robin D Bailey, Agile Coach, GoSourcing
Scale of reference
While story points are useful as an abstraction for planning and estimating, they should not be over-analyzed. In a newly formed team, story points are likely to fluctuate significantly, but there can be more confidence in the reliability of estimations in a long-running team who have completed many releases together. Two different teams, however, will have different scales of reference.
At a company level, the main value I used to seek with story points was to understand any systemic problems. For example, back when Atlassian released to Server quarterly, the sprints before a release would blow out and fail to meet the usual level of story point completion. The root cause turned out to be a massive spike in critical bugs uncovered by quality blitz testing. By performing better testing earlier and more regularly we spread the load and also helped to de-risk the releases. It sounds simple looking back but it was new knowledge for our teams at the time that needed to be uncovered.
Mat Lawrence, COO, Easy Agile
Even with well-established teams, velocity can be affected by factors like heightened complexity with dependencies scheduled together, or even just the average number of story points per ticket. If a team has scheduled a lot of low-complexity tickets, their process might not handle the throughput required. Alternatively having fewer high-complexity tickets could drastically increase the effort required by other team members to review the work. Either situation could affect velocity, but both represent bottlenecks.
Any measured change in velocity could be due to a number of other factors, like capacity shifting through changes in headcount with team members being absent due to illness or planned leave. The reality is that the environment is rarely sterile and controlled.
Relative velocity
Many organizations may feel tempted to report on story points, and velocity reports are readily available in Jira. Still, they should be viewed with caution if they’re being used in a ‘team of teams’ context such as across an Agile Release Train. The different scales of reference across teams can make story points meaningless; what one team considers to be a 8-point task may be a 3-point task for another.
To many managers, the existence of an estimate implies the existence of an “actual”, and means that you should compare estimates to actuals, and make sure that estimates and actuals match up. When they don’t, that means people should learn to estimate better.
So if the existence of an estimate causes management to take their eye off the ball of value and instead focus on improving estimates, it takes attention from the central purpose, which is to deliver real value quickly.
Ron Jefferies
Co-Author of the Manifesto for Agile Software Development
Story Points Revisited
Seeking value
However, story points are still a valuable tool when used appropriately. Reporting story points to the team using them and providing insights into their unique trends could help them gain more self-awareness and avoid common pitfalls. Teams who are seeking to improve how they’re working may wish to monitor their velocity over time as they implement new strategies.
Certainly, teams working together over an extended period will come to a shared understanding of what a 3 story point task feels like to them. And there is value in the discussion and exploration that is needed to get to that point of shared understanding. The case for 8 story points as opposed to 3 may reveal a complexity that had not been considered, or it may reveal a new perspective that helps the work be broken down more effectively. It could also question whether the work is worth pursuing at all, and highlight that a new approach is needed.
The value of story points for me (as a Developer and a Founder) is the conversations where the issue is discussed by people with diverse perspectives. Velocity is only relatively accurate in long-run teams with high retention.
Dave Elkan, Co-CEO, Easy Agile
At a company level, story points can be used to understand systemic problems by monitoring trends over time. While this reporting might not provide an objective measure, it can provide insights into progress across an Agile Release Train. However, using story point completion as a measure of individual or team performance should be viewed with considerable caution.
Story points are a useful estimation tool for comparing relative effort, but they depend on shared points of reference, and different teams will have different scales. Even established teams may notice velocity changes over time. For this reason, and while velocity reporting can provide insights into the team's progress, it must be remembered that story points were designed for an estimation of effort, rather than a measure. And at the end of the day, we’re in the business of producing great software, not great estimates.
Looking to focus your team on improvement? Easy Agile TeamRhythm helps you turn insights into action with team retrospectives linked to your agile board in Jira, to improve your ways of working and make your next release better than the last. Turn an action item into a Jira issue in just a few clicks, then schedule the work on the user story map to ensure your ideas aren’t lost at the end of the retrospective.
Many thanks to Satvik Sharma, John Folder, Mat Lawrence, Dave Elkan, Henri Seymour, and Robin D Bailey for contributing their expertise and experience to this article.
Related Articles
WorkflowThe Ultimate Agile Sprint Planning Guide [2023]
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.
- Product Owner
- Scrum Master
- 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:
- Product backlog
- Sprint backlog
- 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.
- Sprint planning
- Daily scrum (or standup)
- Sprint review
- 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.
WorkflowHow to use story points for agile estimation
Story points can be a little confusing and are often misunderstood. Story points are an important part of user story mapping, and many agile teams use them when planning their work. But they aren't as simple as adding numbers to tasks or estimating how long a job will take.
Even if you’ve been using story points for a while, you’ll find that different teams and organizations will use them differently.
So, let’s define story points, discuss why they’re so useful for agile teams, and talk about some of the different ways teams implement them in story mapping and sprint planning.
What are user story points?
Story points are a useful unit of measurement in agile, and an important part of the user story mapping process. You assign a number to each user story to estimate the total effort required to bring a feature or function to life.
When to estimate story points
User stories can be estimated during user story mapping, backlog refinement, or during sprint planning.
Once a user story has been defined, mapped to the backbone, and prioritized, it's time to estimate the story points. It is a good idea to work with your team to do this, as each team member plays a different role in different stories, and knows the work involved in UX, design, development, testing, and launching. Collaborating on story point estimation will also help you spot dependencies early.It is best to assign story points to each user story before you sequence them into releases or sprints. This allows you to assess the complexity, effort, and uncertainty of each user story in comparison to others on their backlog, and to make informed decisions about the work you decide to commit to each sprint or release.
How to estimate user story points
When estimating story points, you're looking at the total effort involved in making that feature or functionality live so that it can deliver value to the customer. Your team will need to discuss questions like:
- How complex is the work?
- How much work is needed?
- What are the technical abilities of the team?
- What are the risks?
- What parts are we unsure about?
- What do we need in place before we can start or finish?
- What could go wrong?
Tip: If you're having trouble estimating a story or the scope of work is overwhelming, you might need to break your story down into smaller parts to make multiple user stories.
What is a story point worth?
This is where story points can get a little confusing, as story points don’t have a set universal value. You kind of have to figure out what they’re worth to you and your team (yep, real deep and meaningful stuff).
Here’s how it works:
- Each story is assigned a certain number of story points
- Points will mean different things to different teams or organizations
- 1 story point for your team might not equal the same amount of effort involved in 1 story point for another team
- The amount of effort involved in 1 story point should remain stable for your team each sprint and it should remain stable from one story to another
- 2 story points should equal double the effort compared to 1 story point
- 3 story points should equal triple the effort compared to 1 story point… and so on
The number you assign doesn't matter - what matters is the ratio. The story points should help you demonstrate relative effort between each story and each sprint.
Estimating story points for the first time
Because story points are relative, you need to give yourself some baseline estimates for the first time you do story point estimation. This will give you a frame of reference for all future stories.
Start by choosing stories of several different sizes:
- One very small story
- One medium sized story
- One big story
...a bit like t-shirt sizes.
Then assign points to each of these baseline stories. Your smallest story might be 1. If your medium story requires 3 times more effort, then it should be 3. If your big story requires 10 times the effort, it should be 10. These numbers will depend on the type of stories your team normally works on, so your baseline story numbers might look different to these.
The important thing is that you’ll be able to use these baseline stories to estimate all your future stories by comparing the relative amount of effort involved.
Over time, you and your team will find estimating user stories becomes easier as your shared understanding of the work develops. This is where story points become most valuable, helping your team align expectations and plan more effectively.
Make estimation easier
An app for Jira like Easy Agile TeamRhythm makes it easy to see team commitment for each sprint or version, with estimate totals on each swimlane.
Using the Fibonacci sequence for story point estimation
Some teams use the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, 55, 89, etc.) for their story point estimates, rather than staying linear or allowing teams to use any number (1, 2, 3, 4, 5, 6, 7, etc.).
This has its benefits. For example, if you're looking at a story and trying to estimate whether it's a 5, 8, or 13, it's much quicker and easier to come up with an answer than trying to land on the right number between, say, 4-15. You'll likely reach a consensus much more quickly.
This also means you won't be able to average the team's story points to finalize the estimation. Instead, you'll need to discuss the work and decide on the best estimate from a limited set of options.
But it does limit your options - if you have a story that’s more effort than 34, but less than 55, your estimate might be less accurate.
Using story points to estimate velocity
After some time working together most teams will have a good idea about how much effort is involved in each story point.
Of course, timing isn't exact - there's a bell curve, and story points are designed to be an estimate of effort, not time.
But story points (and knowing their approximate timing) can be useful when it comes to figuring out how much your team can get done each sprint.
You should be able to estimate about as many story points your team can manage during a two-week sprint, or whatever timeframe you’re working to.
For example, if your team can usually get through 3 story points per day, this might add up to 30 story points across a two-week sprint. This is your velocity.Velocity is useful for user story mapping and sprint planning. When mapping your user stories to sprints or versions, you can check the total story points and make sure it matches up with your velocity so you’re not over- or under-committed.
As you can see there are a few different methods for estimating work. The best advice is to be conservative and not overload the team.
Over time, your estimations should become more accurate.Using Story Points in Scrum, Kanban, and Extreme Programming
Story points are central to estimation and planning processes in many agile methodologies. Scrum and Extreme Programming (XP) rely heavily on story points to gauge the effort and complexity of user stories.
Scrum teams use story points during sprint planning to decide which tasks to include in the upcoming sprint, encouraging discussion that leads to shared context and understanding of the work.
Extreme Programming on the other hand, uses story points to assess the size of features, enabling teams to prioritize and allocate resources effectively. Teams using Kanban can benefit from story points by using them to set work-in-progress limits and optimize the flow of tasks across the board.
While the specific practices may differ, story points can help encourage team collaboration and a more predictable flow of work.
WorkflowHow to Write User Stories in Agile Software Development
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