Ask a software developer to guess how many jelly beans are in a jar and you’ll probably get some kind of algorithmic reasoning and a frustratingly accurate response.
Guesstimation without reasoning is not exactly a strong suit for most developers.
That’s why estimating the amount of time it will take to tackle projects in order to plan for the following week is often the project most likely to break everyone’s brain.
Enter: story Points. The quantitative answer to this ambiguous question.
So, what are agile story points?
Whereas most teams estimate the difficulty of a task by time—half a day, a week, or a month— story points are a method to measure effort on a relative scale.
Assigning tasks based on relative difficulty allows for a more accurate depiction of the effort expected in the task because, unlike time estimates, story points refer only to the task at hand, not unexpected emails, meetings, or delays that could affect the time it takes to complete the task.
In order to make an accurate estimation of story points, there are a few things to keep in mind:
How to measure story points: the Fibonacci sequence
Developers use a fibonacci sequence: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100, as a metric to measure story points in order to force teams to come to clear decisions.
For example, if you had a project to do and someone asked you if it would take you 3 hours or 4, you may hesitate to answer that question because the difference is so slim it’s difficult to guess.
On the flip side, if someone asked you if it would take you 3 hours or 6, the answer would probably be much more clear.
A few questions to consider when defining story points:
1. Does this project resemble another project we have worked on in the past? If so, what was the effort involved in completing it?
Because story points are a relative form of measurement, the process will continuously change and refine itself, but especially in the beginning, it can be helpful to compare to similar past projects for perspective.
2. Are there any potential unseen roadblocks that could cause a delay?
It is important to consider the whole cross-team journey the product will need to take until it is complete.
3. Will we need to rely on a third party to complete this?
Dependency on another team or outside contractor can result in longer delays and more back-and-forth which should be considered.
Who should plan story points: planning poker and its players
Planning poker is an activity meant to help come up with accurate story point estimates quickly and as a team. In planning poker, each member of the team holds a stack of cards, each of them containing a different story point. One person reads out the different projects the team has coming up, after reviewing all of the details they know about the project each member of the team lays out the card they believe represents the effort needed to complete the project.
This is a fast, efficient, and transparent process for the team to come together around sprint planning.
So, who should be invited to sit around the poker table? It is important to consider the full picture when estimating the effort involved in completing a story, and agreeing on a DoD, or definition of done. Inviting the whole team and adjacent teams such as quality assurance and user testing can ensure you don’t miss any hidden problem areas.
Common mistakes and what to avoid when estimating story points
There are a few mistakes you and your team can easily avoid when working to estimate story points. Be sure to keep an eye out for them and steer your team in the right direction if you begin to veer off track.
- Equating story points to hours
It can be difficult to disassociate time and effort, but once you try to translate story points to hours you have lost the agility of story point estimations and risk getting lost in the details.
- Settling for the average
When planning story points, if half of your team picks 2 and the other half pick 4, it seems natural to agree upon 3—but simply agreeing on an average may be skipping a valuable conversation that could improve your team’s understanding of story point estimations in the future.
- Story pointing tasks that are too big or small
Story pointing small bugs or giant projects can begin to cloud the system and make relative effort allocation more difficult.
- Not keeping reference points updated
It is important that your reference PBI, or product backlog items, are always relevant and up to date. If the task items used as reference for defining story points happened 3 years ago when 70% of the team was not at the company, it’s probably time to update and make sure everyone is on the same page.
Managing story points with templates
Managing all of the product backlog items, the allocated story points for each, and who is assigned to each can get out of hand pretty quickly. Having one sharable and flexible place where your team can manage all story points together makes the process more smooth and clear.
This monday board has everything you and your team need to manage sprint planning and story point allocation. In this template, you can find a progress bar to track the progress of the item, status columns to name the type of product backlog item it is and its priority, and how many story points each item has been attributed. With the sharable board, your team can always be on the same page, and continue to use it as a reference when planning future story points.
Making such a drastic shift in how you think about your team’s projects and planning out sprints can take some time to get used to. Sitting with your team to go through what story points mean, how they will affect your team, and some basic best practices can help you implement story points and manage your sprints easily.
Agile FAQ:
What are agile teams?
Agile teams are a cross-functional collection of employees, freelancers, a group of people, or contractors who come together to solve a specific problem or accomplish a specific goal. Agile teams should consist of everyone needed to finish the project, making them completely independent from influences outside of the Agile team.
Whereas traditional team structures and definitions of success depend on process and product like adding a new functionality or integration by a certain date, agile teams focus on trying to make the most valuable impact which means focusing more on the customer need and how the end-user will interact with the final product. In order to get the most valuable end product, agile teams need to accept last minute, sometimes inconvenient, changes.
What roles exist in Agile teams?
So it’s pretty clear what the goals of an agile team are, but how do you go about building one? There are a few main team functions that should be represented in every agile team to ensure its ability to move fast and avoid dependencies.
One important factor to keep in mind when building your agile team is the size— most agile teams are recommended to stay within five to 8 members. Just tell yourself, if you can’t comfortably fit in a room (or zoom room) together to have a discussion, your team is probably too big.
Let’s check out the main players that make up an agile team:
The Product Owner
Usually in touch with key stakeholders, the product owner is responsible for aligning the project with long-term goals and ensuring things don’t veer off course.
In order to keep everyone moving in the same direction and focused on key goals, the product owner also takes the responsibility of internal communication, making sure all team members are aware of new updates and changes that may affect their project.
The Scrum Master
You can think of the scrum master as the day-to-day manager of the team. They will handle daily prioritization, makes sure the team is working well together, and enforce the practice of agile teamwork.
The scrum master should have some experience working in agile teams and have a focus of clearing obstacles and distractions for the team to work in a highly effective way.
The Team Member
The team members are the ones with their boots on the ground. They are creators and builders that are implementing the vision of the product owner and consulting with the scrum master to make sure everything is running smoothly.
These team members can be copywriters, designers, developers, videographers, or anything in between. The goal of the team members is the execute quickly without compromising the quality.
The ART of agile teams
Implementing agile release train, or ART, is a great way for larger organizations and enterprises to manage agile teams.
An ART is essentially a team of agile teams that come together to focus on common and predetermined goals.
These ARTs are comprised of anywhere from eight to fifteen agile teams that cover all necessary specialties needed to execute initiatives. What the ART will focus on per sprint is determined at a PI planning event where all agile teams within an ART come together to plan their product increments for the next two to three months.
Following the PI planning, each agile team should have an understanding of the ART’s goals and what is expected (in a broad sense) for them to deliver at the end of the sprint.
Building a high-functioning agile team
Remaining steadfastly committed to an agile team structure means constantly reminding you and your team about the true goals and motivators that keep you moving and define where you spend your time.
To do this, it can be best to nail down exactly what the goals of a high-functioning agile team are to use as a north star when your path begins to veer.
7 Goals of high-functioning agile teams
Maintaining strict expectations and working on impactful work that covers deep-rooted needs as opposed to simply putting out fires develops a style of working that is scalable and effective.
Distributed agile teams
It is a widely held belief that agile teams work best together. There are a number of reasons this could be ranging from creativity and problem solving that tend to be stronger with in-person teams to an ability to execute at higher levels—but working face-to-face with your agile team is not always an option.
That does not mean that you cannot build highly effective and motivated agile teams while working from home. But to make sure things stay organized and nimble, you will need ways to clearly define goals, communicate quickly throughout the day, and all stay in the loop instantaneously when changes are made.
To set up the dream remote agile team, we recommend the following best practices and these tools:
1. Zoom for team syncs and retrospectives
Making a habit of syncing as a team and committing to retrospective meetings will ensure your team still feels like a team and are all equally committed to continued improvement
2. staging-mondaycomblog.kinsta.cloud for big-picture planning and cross-team alignment
Having a Work OS where all teams plan, track, and execute their daily work ensures that everyone has access to important updates, files, and Agile project planning. Getting started with planning for an agile team is simple with an organized board that brings everyone together. You can get started right away with a staging-mondaycomblog.kinsta.cloud for agile teams template.
Get Started!