The importance of predictable velocity

Predictable velocity

Introduction

The predictable velocity is the ability to always know the volume of work that will be implemented by a team for a given time based on team’s availability.

The problem of varying velocity

When velocity varies between sprints, planning the release of a project becomes a tough process. It is never known when the tasks will be delivered and so the whole scrum process is broken. The sense of chaos is everywhere and that doesn’t help in improving team’s motivation.

Usually, the varying velocity is caused by the fact that individual team members try to deliver the best they can and they promise more than they can fulfill. Unfortunately, in a collaborative environment with a development process that is well set up, there is a bit more than just the straight-forward implementation of a task. Some team members get lucky and land on tasks that can be implemented relatively simple, but others hit a problem nobody has thought of in advance. In the end, during one sprint the team has a higher velocity (due to finalizing carry-overs), while during another sprint the team has a lower velocity (and cause carry-overs).

Having carry-overs causes the feeling that the job is not well done, the team can do more, but always something happens, something unpredictable. The management raises feels the problem, sees the failing deadlines and this creates a tension among team members.

Regular sprint with carry-overs
Regular sprint with carry-overs

The common problems in maintaining predictability

The problems depend on the project specifics, but many of them are common to all types of projects and will be addressed here with appropriate solutions.

Expect the unexpected

There are some tasks that require research prior to starting. Imagine, for example, some feature that requires interaction with a third party company that may not immediately respond when it is needed. Or this can be a feature that actually cannot be implemented in a straight-forward way due to a wrong understanding of the underlying technology when creating the task.

If such a task is added in a sprint without the needed research in advance, there is a high risk that it takes more time than expected and it will be considered “underestimated”. Some may argue that there is a need for a spike in advance to do a research on the subject. But how to know for which task a research spike is needed?

The only way is to start working on a task in advance. When the work on a task starts before it is actually planned makes it possible to find all issues before they actually occur. With such an approach, the task will be placed in a sprint only when it is absolutely clear and some amount of the work on it is already done.

Sprints with tasks started in advance
Sprints with tasks started in advance

Avoid fuzzy task definitions

Some tasks are defined in a way that they look ok-ish to their creator but do not include important details in their description. There are some implementation specifics that may seriously affect the task fulfillment.

Business people may argue that there must be no technical details in the task definition, but on the contrary, technical implementors find the business requirements too fuzzy to work on.

The solution is to have technical design documents in which the implementation task is referenced. Then it is clear from the technical point of view what exactly needs to be implemented.

It is also good to place technical details in the tasks’ description so that implementors know what needs to be done and some details can ring a bell for possible issues.

Decrease your capacity in a Fibonacci row

Sometimes team members go on vacation or there are holidays during the sprint for all team members. Training and other internal company events also contribute to lowering the team’s availability (the volume of work on project tasks). In this case, the capacity has to be lowered according to the missing people.

The velocity is considered constant, but it is calculated based on the average velocity of all people in the team. For simplicity, let’s look at the case when one person does one story point per day. If one person is missing for one day, the sprint’s capacity has to be lowered with 1 story point. If 2 people are missing for 2 days (2×2=4 story points), the capacity should be lowered with 5 story points instead. Finally, if 2 people are missing for 3 days, the capacity should be lowered with 8 points instead of 6 to include the dependencies risk.

Committing less capacity than calculated
Committing less capacity than calculated

Avoid dependent tasks

In many cases, one task is done by one person and it is a dependency of another task done by another team member. This causes in-team or inter-team dependencies. When the first task is not implemented on time, all dependent tasks are pushed back. This causes team members to idle and then rush when dependencies are done and this way misusing the precious time at work.

Dependent tasks can be started earlier so that when the next sprint starts the first critical tasks on which the others depend will be almost completed. This will reduce the dependency impact on the team’s velocity for the current sprint.

Estimate honestly

Giving honest estimates to tasks is a tricky task and it involves the attention of the whole team. Everyone should be careful and give estimates without being affected by other team members estimates. Only honest estimates can properly show how much time it will take for an epic to be completed and the release dates matched.

The tooling

Scrumpy Planning Poker is a great tool to keep team members attention during the refinement sessions and make fun out of voting. It works on all platforms inside the web browser and can be used to define the story points for implementation tasks. You can start your first Scrumpy Planning Poker session right away!

Try BETA!

Tutorial

The next video shows how easy it is to vote for a task and estimate it with Scrumpy Planning Poker.

How to correctly estimate the release deadline

Predictable deadlines

Introduction

An important aspect of project management is properly estimating the project’s release date. But how can you be able to predict at what date exactly, a big complex system can be delivered?

The estimation problems

To be able to deliver a project on time, the delivery date has to be properly calculated based on the correct tasks estimation. Estimating the tasks is usually a tough process, especially when you have to work with time-based metrics and provide an exact period in which a task should be completed. From a psychological point of view, committing to time for implementation of a task is hard and always prone to failure.

The problem with time

The reason why estimating time is problematic is relatively simple – the more complex the task is, the bigger the chance of not meeting the deadlines. On top of that, it really depends which team member picks which task. People in the team have different velocity and deliver a different volume of work. Due to the changes in the availability of different team members (vacations, training, etc.) sometimes a task estimated by the most performing team member can end on the desk of the least performing one. Then the nice Gantt charts become a mess – tasks become overdue and managers are always concerned if the project will be completed in time.

Broken Gantt chart
Broken Gantt chart

The resistance against time estimates

When implementors of a task are asked to give an estimate, there is always a resistance – if the estimate is not met then who is to blame? Also, when a task estimated by one team member lands for some reason on the desk of another team member, who is to blame when the estimate does not match the actual time spent?

All this leads to an unwillingness among team members to estimate tasks. This resistance creates difficulties for the management to properly estimate the delivery dates.

Using story points

There is an alternative approach to using time-based metrics for estimating tasks – using story points. The story point is not a fixed unit of work, but an exponentially growing relative estimate. The estimates are given by the whole team during the refinement sessions.

Example storypoints
Example estimates

Sharing responsibility

By using story points, the whole team gives an estimate for each task. The estimate is accepted when all team members agree on it. This saves the discussion later who estimated it and how much time was actually needed to complete the task. There was an initial agreement between team members and responsibility is shared.

Estimating complexity

Story points are used to estimate the complexity of a task, including its external dependencies and any risk if something might go wrong. Since it is not a commitment to a physical metric like time, such estimates are given with ease by the team.

The smallest estimate

Since story points are relative, there must be an anchor from which to start. The anchor for the relative estimation is the smallest unit of work that requires some implementation effort. This is the least volume of work which the team is able to estimate.

The smallest estimate
The lowest estimate

The biggest estimate

Story points are exponentially growing to indicate that the more complex a task is, the more difficult it is to estimate it. Story points can grow up to the  (infinite) estimate. The infinite estimate though is rarely used. The biggest estimate should be the largest unit of work that can be implemented by one team member on the average for one sprint. And the length of the sprint itself is evaluated by the biggest unit of work that can be done by a person on the average without losing control on the task.

The stories that are bigger than the biggest estimate

Some tasks are estimated by the team with higher story points than one person can implement within a sprint. Placing such tasks in a sprint will cause carryover. Carryovers are not good as they leave the feeling that the sprint is not complete and the job is not well done. To avoid this, tasks that are estimated higher must be split apart into smaller units of work and estimated again.

Splitting 13 story points
Splitting 13 story points

The story points velocity

The velocity can be measured in average story points per person per time actually spent on tasks (availability). The capacity is a metric for the volume of work a team can do for a given time based on its velocity.

capacity = velocity * availability

This metric can be converted to time and the release date correctly estimated. When the velocity is predictable, the project’s release date can be punctually estimated. Based on story points and sprints, the new fixed and predictable Gantt chart would look like this:

Fixed Gantt chart
Fixed Gantt chart

The tooling

The Scrumpy Planning Poker application is a useful free tool that allows estimating tasks in a collaborative way both by colocated and distributed team members following the Planning Poker rules. The refinement session is lead by the Product Owner (PO)  or the Scrum Master (SM). You can start your first Scrumpy Planning Poker session right away!

Try BETA!

Tutorial

The next video shows how easy it is to vote for a task and estimate it with Scrumpy Planning Poker.