28 July 2022
A successful project starts with planning and evaluation. Without a detailed roadmap, you risk ending up in the chaos of missed deadlines, underestimated tasks, and failed objectives. Agile story points estimation methods help developers see the bigger picture and update a client on approximate budgets and timeframes.
The Rocketech experts have prepared a short overview of the swimlanes project estimation to explain the method’s process and goals.
Relative Estimation Methods
The cornerstone of the agile software development approach is estimating what needs to be done in story points rather than in hours. Although relative estimation methods pose certain challenges in communication with the client, they have long proved efficient.
The difference between absolute and relative estimations is that the latter compare tasks to each other rather than assign them a number of hours for completion. It makes the process easier and minimizes arguments and contradictions.
It is much easier for the development team to agree on the relative size of a work item than to estimate its development in hours. However, there usually should be a reference task to depart from. Typically, they are set by default according to the team’s previous experience.
The number of points assigned to a story represents its total size. There is no definite formula for determining this size. Point size is more of a combination of the task’s complexity, risks, and the team’s expert level.
Over time, developers invented different relative estimation methods, including:
- Poker Planning
- T-Shirt Sizes
- Swimlane Sizing
- Maximum Size or Less
- Bucket System
- Dot-Voting
- Big/Small/Uncertain
- Ordering Rule
Generally, you can use any real (or not real, for that matter) concept as an estimation point. Some developers use dog breeds, for example. At Rocketech, we successfully apply swimlane sizing for fast and effective high-level assessment of new projects.
What Are Kanban Swimlanes?
Kanban is an agile workflow management method. Being neither a methodology nor a process framework, it’s a much less structured approach than Scrum. However, you can apply Kanban to any already-running process. The method is based on visualizing the changes through gradual improvements on a Kanban board.
Tasks move through horizontal columns on the board from left to right as their status changes. The simplest example is a journey from “To Do” to “In Progress” to “Complete”. Besides columns, Kanban boards have horizontal “swimlanes” denoting different task types. They can be assigned to team members, teams, clients, repetitive tasks, classes of service, or any other label. The Kanban swimlanes became the basis for the swimlane sizing project estimation method.
Swimlane Sizing Explained
Visually, the swimlane sizing technique resembles the Kanban board. The method has a particular “operational protocol” and helps teams quickly assess backlogs and adjust their size.
“This approach keeps numbers entirely out of the mix until the end and allows participants to focus solely on the relative sizing of stories”.
The Process
For the swimlanes project estimation process, you need a table the developers can walk around. Use sticky tape to create 8 “swimlanes” on the table.
Then put incomplete user stories for the upcoming Sprint (written on cards or sticky notes) on the table. Important: Don’t label any lanes with numbers or other markings.
That’s how the table should look like:
Divide the user stories among the developers and ask them to classify the cards without discussion. It should be approximately five minutes of silent placing the cards on the swimlanes with story size increasing from left to right—the smallest stories in the left-most lane.
Important: Don’t mention story points or any other number—the team needs to compare stories to each other. However, you can guide the developers through the first one or two stories to provide them with some “anchors” for further classification.
The board should look like this (including some card grouping); Xs are the user story cards:
After all user stories have been placed, developers spend another five to ten minutes silently moving the cards to other lanes, according to their team members’ decisions. Some user stories are likely to be pushed back and forth. If this happens too often, allow the timeboxing, allocate the card to the largest option or remove the story.
The board should look a bit different from the first round:
After placing and reviewing all cards, ask the team members how satisfied they are with the current board layout on a scale from 1 to 5. Those who indicate 1 or 2 should elaborate their concern. Then, other team members are encouraged to either explain their point of view or agree to move the card. Many experts advise timeboxing these discussions to two minutes per team member.
The developers then determine whether there could be a smaller user story than the one in the leftmost lane. If not, the first column should be labeled 1 or 2. The choice is based mostly on judgment and instinct. If the developers believe that smaller user stories are possible, this lane gets 3 or 5.
Then the remaining swim lanes are numbered by the modified Fibonacci sequence used for story point estimation (0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100, !/?).
In the end, you should get a table looking like this:
- Typically, 5 is a “medium” sized story for a sprint.
- Anything larger than 8 to 13 requires decomposition.
- Anything larger than 20 is unknown. It needs further discussion, examination, and decomposition before you can size it effectively.
Important: Leave the far-right column unsized. Stories in this lane can be broken down into smaller parts. This way, you’ll have space for draft exercises, not yet ready for commitments.
For more detail, check the source.
The Purpose
Such “silent classification” is a powerful estimation instrument in agile environments. It eliminates unnecessary debate and encourages focused thinking. The dynamic estimation approaches (often purposefully limited in time) help people discuss user stories and dive deeper into the ways of their realization.
The method allows you to estimate a great number of user stories for a short time. I know the cases when a team estimated 40 stories in 1.5 hours. At Rocketech, we successfully discuss and estimate 12-15 user stories for an hour.
Anastasiia Musil, Scrum Master, Rocketech
The swimlane sizing requirements don’t include the active discussion participation of every team member. Although the entire team is present at the exercise, it’s not mandatory to express your thoughts if you don’t want to, unlike in planning poker.
The swimlanes project estimation formula is a high-level assessment approach, even more approximate than (again) poker planning. It doesn’t aim to break every task into the smallest elements and reach a complete consensus. The goal is to go through all tasks and understand the project as an overall picture.
Final Thoughts
Quick and effective planning helps developers minimize problems and start communication with the customer on the right note. And no planning is possible without an assessment of the work ahead. Different project estimation techniques typically serve varying purposes. While small projects require less effort, evaluating large, complex ones can become a challenge itself.
The swimlanes project estimation methodology is a quick and efficient way to provide a client and a team with an overview of requirements and workload. Along with poker planning, it’s our proven go-to technique we perfect with every successful project. Interested in our project estimation methods? Contact us for more detail.