Introduction
It is quite a challenge to compare agile teams and find out really why teams should be compared at first place. How can the agile process benefit from comparing teams working on different tasks from different domains?
Creating a competition
Definitely, teams shouldn’t be compared directly and challenged one against another just because of different metrics. This can only create a demotivation. Instead, metrics should be only used to create an equal opportunity for each team to compete with the rest. This way, performance is increased indirectly, by the will of teams, not from an outside urge.
The metrics for creating equal opportunities
Below is a list of basic metrics that can be used to measure differences between teams. Those metrics show nothing more but the ability to compete with the rest of the teams on equal grounds. Equal metrics mean equal opportunity.
Successful sprints
If the sprint is just a time frame, it wouldn’t make sense to have sprints at all. It is a milestone and should have a goal. The sprint goal (the most essential set of stories in the sprint) is the bigger milestone and the successful sprint (all stories completed) is the smaller one. You can bring life to sprints by scheduling cross-team sprint demo at the end of the sprint where teams present their achievements. This way teams will compete with each other to show a successful sprint and the achievements accomplished. You can’t motivate without showing the goal to reach.
Can this be a game of over- and under- commitment? When the team under-commits, it would be obvious to the others during the sprint demo – there will be fewer achievements. If the team over-commits, the presenter will show a yet another failed sprint. The feeling that the team did something successfully according to the plan unlocks a motivation to deliver more. Teams are satisfied by the work done.
Velocity stability and the honest estimation
It is a knowledge work indeed and not a factory assembly work, but when there is no knowledge in the whole team to understand a problem and estimate its solution, this means that the problem was not researched in advance.
A time-boxed spike in the previous sprint to create a research paper on the subject plus a document review from the whole team will make it easy to split the implementation into smaller stories and properly estimate them. For complex tasks, a bigger technical design document is needed with a list of implementation stories.
The spike and the creation of the technical design document are again a set of stories that can be properly estimated. It is all about defining well the structure and sequence of tasks to implement a more complex solution. You can avoid placing a story for which there is not enough knowledge in the team, but instead make a task to research and gain this knowledge. Then estimation is easy and accurate.
Capacity predictability (avoiding unexpected work)
Research can be done first, implementation will follow later. During the research problems pop-up, tickets are created and estimated. You can know well enough what will follow the next sprint. What is known can be estimated and planned. What is not known can have a time-boxed research ticket and again estimated and planned. It is all about properly splitting the bigger task into smaller chunks.
Complex tasks can be started in advance, even if just to find out a separate set of stories need to be created. But still, it helps to control the risk from the unknown.
Support work and firefighting unexpected production issues are usually done in time-boxed Kanban mode outside the sprint where time to first response and SLA breaches on critical issues are used for comparison metrics between teams.
Team availability (time spent on tasks divided by total time in a sprint)
This is what the team did while the team members were working on estimated tasks. If a team gets more distraction than other teams (technical courses, knowledge sharing, or other internal tasks outside the sprint), this means that it is time to take actions to make availability equal between the teams. This is the time that is spent on estimated tasks and the only way to keep velocity stable is to keep availability stable. When the availability between teams is equal, then the other comparison metrics will work.
Conclusion
Comparing teams is not about punishing the low performance, but about increasing the motivation and spirit to compete and deliver more. That’s why those metrics should not be visible to individual team members. By keeping control of the comparison metrics above with indirect guidance to scrum masters, you can give equal grounds to teams to compete with each other.
The tooling
Scrumpy Planning Poker is a great tool to use for providing honest estimations and achieve a stable velocity by keeping the whole team engaged. You can start your first Scrumpy Planning Poker session right away!
Try NOW!Tutorial
The following video shows how to use the Scrumpy Planning Poker application by becoming a moderator and creating a refinement session. Scrumpy Planning Poker saves you time and keeps your team engaged!