Velocity Starts with Alignment
Velocity is a simple idea that’s often misunderstood. It measures how much work a team has completed in a sprint, and over time, it can show an average that helps teams plan what’s realistic for the next one. It’s a useful guide, but it’s not a goal in itself.
Some teams treat velocity like a target or a competition (and some are pushed to). They try to “set” it higher or compare it across teams, hoping it will prove that they’re getting faster. But velocity is not a budget, a forecast, or a speedometer. It’s a reflection of real progress made by a team working together, not a scoreboard of individual performance.
Used well, velocity helps a team understand their delivery rhythm and make sustainable plans. Used poorly, it can create pressure, encourage over-commitment, and hide the very problems it’s meant to reveal.
That’s why alignment matters. When a team plans together, estimates together, and agrees on what success looks like, velocity becomes a sign of steady progress rather than a race for points.
Where real pressure comes in: leadership, metrics and expectations
Team velocity often becomes a target not because the team wants it that way, but because leadership or stakeholders push for higher numbers. Community threads and agile commentators repeatedly flag this.
1. Metric as performance tool rather than guide
In “Is Measuring Velocity in Scrum Good or Bad for Your Team?” our partners at CPrime warn of risks to team morale and performance when teams are compared based on velocity. When velocity is viewed as proof of output, pressures mount to inflate estimates or cram more work.
2. Unrealistic demands from above
Teams feel the squeeze when leaders look at velocity charts and ask “Why can’t we do more?”. This shifts the burden to the team rather than the planning process. In practice, such demands lead to corners being cut, assumptions going unchallenged, and real issues being hidden. After all, increasing velocity by 20% could be as simple as inflating estimates by 25%.
3. Misuse of comparisons and individual “velocity”
Some leaders want to pit teams against each other or measure individuals. According to the Agile Alliance, “only the aggregate velocity of the team matters, and the phrase ‘individual velocity’ is meaningless.” That misuse causes resentment, gaming metrics, and fractured collaboration.
4. Volatility triggers pressure, not insight
When velocity swings — up or down — leadership often responds with mandates rather than inquiry. But those swings often signal real issues: unclear stories, unexpected dependencies, or overcommitment. Treating them as failures rather than clues deepens the challenge.
What alignment really means
Alignment is not a meeting. It is a shared understanding that connects planning, estimation, and delivery. When a team is aligned, everyone sees the same goal, understands what it will take to achieve it, and recognises where the risks lie.
But if alignment were easy, misalignment wouldn’t show up so often. You can usually spot it when planning feels tense, with people talking past each other, or it goes completely quiet as no one feels confident to speak up. Estimates vary wildly, or work shifts mid-sprint because the team never agreed on what “done” meant. All of this points to the same issue: the team doesn’t yet share a clear, common understanding of the work.
True alignment happens when planning and estimation happen together. Teams discuss what matters, how complex it is, and how confident they feel. Product owners bring the context, engineers share the technical view, and designers help surface dependencies. Together they build a realistic plan that connects the work to the outcome.
Once this shared view exists, estimates and velocity reflect understanding rather than guesswork. The team can plan with more confidence and adapt with less stress. Alignment is what yields the real progress.
How alignment is built in practice
Alignment doesn’t happen by accident. It’s shaped through open conversations, shared visibility, and habits that keep everyone working from the same plan. Tools support this, but alignment comes from how people use them together.
1. Start planning from shared priorities
Begin with what matters most. Sprint goals or high-level initiatives help anchor the discussion before you get into the detail of breaking down tasks. When everyone sees how each story connects to an outcome, decisions stay grounded in value and you reduce the opportunity for strong opinions to have undue influence.
2. Estimate as a team, not as individuals
The benefit of estimation comes from the conversation and the opportunity to share understanding. When people share their view of effort and complexity, hidden assumptions can surface early and be clarified. The Planning Poker feature in TeamRhythm makes this easy to run inside Jira, keeping the discussion focused on the work itself.
3. Keep priorities visible and current
Goals that can’t be seen are quickly forgotten, but a live view of the sprint in Jira helps everyone see what’s next, what’s at risk, and what’s already done.
With TeamRhythm, teams can set clear goals for each sprint or iteration and see how every story connects to those goals. User stories sit under epics, showing at a glance how work is grouped and how each piece contributes to the bigger picture. The story map view keeps this visible to everyone, without adding extra admin.
4. Revisit alignment often
Alignment isn’t something you agree on once and then take for granted; it needs small, regular check-ins. The daily stand-up is a great time to do this. Use stand-ups to confirm what still matters most, discuss any new dependencies that have surfaced, and make quick adjustments before things slow down.
When you keep alignment visible in this way, it becomes part of how you work rather than another meeting to run. The plan stays shared, delivery feels steadier, and progress is easier to trust.
Turning alignment into confidence
Alignment is about giving people the clarity and trust they need to work as a team with confidence. When the whole team understands what matters, what’s achievable, and how their work contributes, they can move forward with focus instead of hesitation.
That shared understanding encourages open conversations, early problem-solving, and flexibility when things change. People feel comfortable speaking up because they know their perspective helps shape the outcome. Those are the building blocks of steady progress.
With that kind of clarity, velocity becomes a reflection of how well the team works together rather than how quickly they move. The numbers stop creating pressure and start showing evidence of reliable delivery.
Confident teams make thoughtful decisions, adapt to change without losing direction, and keep delivering work that truly matters. That’s what alignment makes possible.
Related Articles
WorkflowPlanning Poker — Agile Estimation Technique How-to Guide
One of the core functions of an agile software development team is effort estimation. You can't properly prioritize a product backlog without first having an idea of the amount of work it will take to finish each of its user stories. One agile estimation technique is planning poker. Agile development is a collaborative pursuit, and planning poker is a consensus-building exercise that gets your entire team involved in the estimation process.
Software development teams use planning poker to assign effort (for example, story points or ideal days) to items in their product backlog. Sometimes also called Scrum poker, it's a gamified way to build consensus by allowing all of the Scrum team members to participate in the estimation process. Physical or digital poker cards are used to facilitate a collaborative planning session. ♠️
Here, we give you a how-to guide to planning poker. First, we'll show you how to play it in the context of a sprint planning meeting. Second, we'll look at some of its benefits as an estimation technique. Then, we'll see why planning poker can be used in product roadmap planning. It can help get your stakeholders involved in a consensus-building estimation session around your product's customer themes.
Playing planning poker — agile collaboration
One of the critical activities for agile teams during a sprint planning session is estimating the amount of effort it will take to complete each user story in the sprint. A common way to do this is to allow a single person, like the product owner or a software developer, to assign story points to each user story. Alternatively, you can use planning poker as an estimating technique to get the whole team involved.
A planning poker session is a fun and collaborative way to gamify sprint planning. After all, the Agile Manifesto highlights the value of collaboration and interactions in software development. Planning poker is a great way to adhere to those agile principles.
So, it's sprint planning day. When your team members are gathered, do the following:
- Set the stage. If your team is new to planning poker, explain the process. They'll use playing cards to estimate the size of each user story in the next sprint iteration. The product owner or Scrum master will act as the moderator, all team members will play, and there will be plenty of room for discussion and questions throughout the session.
- Hand out the poker cards. Give each player an identical set of numbered cards. We recommend using the Fibonacci sequence — 0, 1, 2, 3, 5, 8, 13, 21, etc. (To read why this sequence is so effective for estimating, see Mike Cohn of Mountain Goat Software's explanation.) And by the way, if you can't meet in person and are planning as a distributed team, then you can try planningpoker.com as a way to conduct your session remotely. 😃
- Read a user story. The moderator reads the team members a story from the sprint. They should provide as much detail and context as possible to help the team estimate the work involved.
- Discuss the story as a group. First, let the team ask any clarifying questions about the user story that was just read. Then, open the floor for discussion — each team member can describe what it will take to get the story done, any dependencies blocking the work, and who on the team might need to be involved in its effort.
- Play cards. Now, it's time to play the game. Each team member submits a card (face down!) to the moderator. When all the playing cards are submitted, the moderator reveals what each one estimates. In an ideal world, all of the numbers match! This means there is perfect team consensus about the effort required for that sprint item and you can move on to the next one.
- Discuss and estimate again. Most likely, there will be some difference in the initial estimates. This gives each team member a great opportunity to provide support for why their estimates were either higher or lower than the others. Then, you can do another round of submitting and revealing cards to see if there is further consensus. Tip: Let the moderator decide when to end the round. Remember, you don’t need a perfect story point consensus for every user story.
You did it! Your sprint is planned, and the entire team gained a shared understanding of how each member perceived the effort and work needed to get each user story done.
The benefits of planning poker agile estimation
As an agile estimating and planning technique, planning poker has its pros:
- It encourages collaboration. As a cross-functional team, it's important that each team member has a voice during the estimation process. As each estimator provides their perspective on a user story, the group better understands how they arrived at their conclusion.
- It drives consensus amongst your entire team. With each round of planning poker, the team’s estimates are more likely to converge.
- It has documented merit as a more accurate way to estimate (versus a single person providing the estimates).
In a study published by ScienceDirect, planning poker was used to estimate half of the work of a software project. There were two discoveries. First, planning poker estimates were statistically higher than individual estimates. Second, the poker estimates turned out to be more accurate than the individual estimates for the same tasks.
Planning poker for roadmap planning
Planning poker is a fun and effective way to gain an accurate estimate for your product backlog items. But, why not also use it for strategic planning sessions like roadmap planning?
In our definitive guide to product roadmaps, we discuss how roadmaps focus on big-picture, customer-centric themes, as opposed to individual features. We also highlight that developing your product roadmap should be a collaborative process (just like sprint planning) and should involve multiple stakeholders.
So, go back to the steps above. Think about how you can use planning poker cards to get your relevant stakeholders to estimate the relative size of each customer theme in your product roadmap. It will be a fun way to get a big-picture consensus of your organization's product vision.
Grouping your themes
Planning poker is a collaborative way to get the whole team to help estimate the work involved in a user story. It drives consensus and tends to be more accurate.
If you use Jira to conduct your sprint planning meetings, you already have a tool that organizes your user stories and product backlog. As you try planning poker in your next product roadmap planning meeting, give Easy Agile User Roadmaps for Jira a look. It provides the ability to group Jira items into themes that your stakeholders can easily see. Happy playing!
Agile Best PracticeThe 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 RevisitedSeeking 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.
Agile Best PracticeSix Tips for Improving Team Collaboration
The 17th State of Agile Report shared that 93% of executives thought that their teams could do the same amount of work in half the time, if their teams collaborated better.
That's quite a statistic. We’ll leave it up to you to decide whether this reflects a lack of efficiency due to poor collaboration, or a disconnect between leadership expectations and the realities faced by development teams.
What we do know is that improving team collaboration has benefits and that improved collaboration is a key benefit of effective agile practices.
So if you think your team could work more effectively, here are six tips for improving team collaboration that we think will make your working life better, and help you deliver for your customers.
1. Agile Teams Are Cross-Functional
Cross-functional teams are the backbone of agile collaboration. It's Agile 101:
The best architectures, requirements, and designs emerge from self-organizing teams.
Manifesto for Agile Software Development
Ideally, your agile team should be able to deliver work independently. The skills and expertise of your team should allow you to handle diverse tasks without creating dependencies on other teams. You can take ownership of the software you're delivering.
The benefit of organizing into cross-functional teams is a greater shared understanding of your project, where you can each see how the pieces fit together. This type of collaboration supports the efficient flow of work and ensures that knowledge and skills are consistently shared.
2. Take an Iterative Approach
Or to put it another way, make it easier to fail fast, so your team can learn why, and correct your course. By breaking down large projects into manageable increments, your team can focus on delivering small, functional parts of working software at regular intervals. This approach goes hand-in-hand with continual feedback from users, ensuring that issues are uncovered quickly and dealt with just as fast. This shared team focus on user feedback, and the shared purpose and collaboration that comes with it, is a key benefit of agile development.
3. Maintain Regular and Transparent Communication
Daily stand-ups, sprint reviews, and planning meetings are all designed to foster regular and clear communication. You and your team should see these meetings as an opportunity to share ideas, discuss progress and blockers, and collaborate. If your daily stand-up is nothing more than a shopping list of tasks, then you're doing it wrong.
If your daily stand-up is nothing more than a shopping list of tasks, then you're doing it wrong.
Someone who has wasted too much time in shopping-list meetings.
Beyond team meetings, clear communication is important anywhere the details of your work are shared. Agile tools like Easy Agile TeamRhythm provide a central platform for prioritizing work and tracking progress. With a central source of truth that everyone can access to understand goals, priorities, and team commitment, collaboration can be more effective, keeping the team aligned and focused.
4. Conduct Team Retrospectives
Hot take: regular retrospectives are the most important agile practice your team can adopt.
Team retrospectives provide a structured opportunity to reflect on your work and discuss how it can be done better next time. This is team-led improvement because you and your team are in the driver's seat. Encouraging honest and open discussions during retrospectives helps build trust among team members and fosters a collaborative mindset. By continuing to work on processes and behaviors, you and your team can improve your performance over time and make your working life better.
5. Use Collaboration Tools
The right tools can make a big difference in team collaboration. The best tools provide a reliable source of truth that the whole team can access, in a place where the whole team will access it. It's a simple concept; a shared understanding of the work is supported by shared and willing access to the same information.
Choose a tool that makes it easy for you and your team to access information and keep it updated. If you're already working in Jira, an integration like Easy Agile TeamRhythm provides a better view of your work in a story map format, with goals, objectives, and team commitment all made clear. Team retrospective boards are attached to each sprint (or spun up as required for Kanban teams) so you have your team-led ideas for improvement tightly connected to the work in Jira.
No matter which tool you choose, make sure it will facilitate better alignment, streamline your workflows, and provide a clear picture of roadblocks and progress. By using collaboration tools effectively, your team stays organized, focused, and connected, no matter where each member is located.
6. Build a Positive Team Culture
It may sound obvious, but a positive team culture is essential for effective collaboration. Creating an environment where team members feel valued, respected, and motivated, encourages the psychological safety they need to share their great ideas, learn from missteps, and collaborate more effectively with their colleagues.
High-performing teams recognize the achievements of others, share constructive feedback, and support practices that lead to a healthy work-life balance. Make it regular, and keep it authentic. A positive culture not only improves team dynamics but also boosts overall productivity and job satisfaction.
Successful Team Collaboration
Effective collaboration can be the difference between your team achieving their goals, or falling short. By embracing agile practices like the regular communication that comes from agile planning meetings, to the learnings that come from taking an interactive approach to development, and creating time for team-led improvement with retrospectives, you can seriously boost your team dynamics.
Easy Agile TeamRhythm Supports Team Collaboration
Easy Agile TeamRhythm is designed to make your agile practices more accessible and effective, helping your team plan, prioritize, and deliver work with better alignment and clarity.
Built around a story map for visualizing work and retrospective boards that encourage team-led improvement, TeamRhythm facilitates sprint and release planning, dependency management, backlog management, user story mapping, and retrospectives.
Tight integration with Jira makes Easy Agile TeamRhythm a reliable source of truth, no matter where you and your team members are located.
Watch a demo, learn about pricing, and try for yourself in our sandbox. Visit the Easy Agile TeamRhythm Features and Pricing page for more.
Easy Agile TeamRhythm