Sheepherding story points

Sheep Effect

Introduction

Most of the time estimating with story points is neglected and performed in chat rooms where all messages are visible, or verbally when everything is audible.  Knowing how other people voted for a story estimation twists the outcome of voting and the result is not correct. An incorrect estimate repeated for several stories leads to wrong business plans and delayed or canceled deliveries. Let’s investigate what happens in an open vote.

The characters in voting

There are several characters participating in an open estimation vote. Depending on who goes first, the story gets estimated differently, but mostly far from the honest estimate.  Why does the open vote make it that significant who goes first? Because of the sheep effect, other team members tend to copy the original estimate.

The sheep effect
The sheep effect

The “I know it all” team member

Every team has at least one member who thinks he/she has the most knowledge of the system. Usually, this is the first vote since things are known. There are often overseen details though that can spoil the expectations. Those details can be discovered in advance, but only if a discussion is provoked. This cannot happen in an open vote.

The “I know it all” team member usually votes with a lower estimate than the honest estimate. Probably only this team member can execute the estimated story for that little time and only when he/she gets lucky.

Mr. I know it all
Mr. I know it all team member

The rest of the team members vote the same so at the end, it appears that the estimated task is easy and anyone can do it for the appointed time. Unfortunately, often this task is picked by other team members.

The “Introvert” team members

Usually, those team members are more than one and they are afraid to be the first voters. They expect someone else to vote first so they can repeat the vote. They rarely participate in any conversation for a particular issue of a story and reply only when being asked. The introverts vote second, just before the “I don’t care” team members.

The introvert team member
The introvert team member

The “I don’t care” team members

During implementing stories it is difficult to catch those team members, but during the vote, it is most obvious. They always vote last and repeat the estimates of the others. If the estimates are different, they announce the one that repeats most. The reason is that they don’t want to be asked questions why a lower or a higher estimate was announced. They never collaborate during the refinement session and desperately try to avoid any questions being asked.

I don't care and don't know
I don’t care and I don’t know team members

The Tired employee

Some of the team members just can’t stay focused for a long time and so they miss some important part of the discussion. For various reasons they lose context in the conversation and tend to give random story points to tasks or desperately try to find out what is the most repeating vote so they can copy it.

Mr. Sleepy Tired
Mr. Sleepy Tired

How to keep the attention during estimation

Estimation is important since only the honestly assigned story points can bring a project flawlessly to the release date. The most important part of the honest estimation is to never allow team members to leverage the sheep effect by using special estimation tools like paper cards or software.

The team members should never see each other’s estimates until they are revealed by the moderator. This way Introvert starts thinking, Mr. “I don’t care” gets interested and Mr. “Sleepy Tired” wakes up. The best question to ask, especially when deviating from the average voter is “why did you vote X story points”.  This will provoke some conversation, some discussion with the moderator on the real implementation issues for the story. The close-ended questions like “would you agree” with X story points automatically lead to the useless answer “yes”.

With an estimation tool that brings some joy to the boring refinement session and requires each team member to stay awake and ready to discuss, it is no longer difficult to give proper estimations even to complex stories.

The tooling

Scrumpy Planning Poker is a great tool to keep team members attention during the refinement sessions and properly estimate stories in Jira (and not only). It helps team member stay awake, have fun and estimate honestly even the most complex stories. You can start your first Scrumpy Planning Poker session right away!

Try NOW!

Tutorial

The following video shows how quick and easy it is to start a refinement session, personalize the theme and language and estimate stories honestly. Scrumpy Planning Poker is fun and engaging!

The 10% scrumban rule for every sprint

The 10% Kanban rule

Introduction

It is a common practice for many Scrum Masters to commit to the exact capacity displayed in the Jira Portfolio. This is often not the right approach and leads to failed sprints. The simple question is why this happens when the capacity calculations are so punctual?

The rush to deliver more

Product owners tend to push towards increasing the velocity after every successful sprint which looks like a natural reaction to the latest achievements. As the team completed a certain amount of story points last sprint, it is expected that it can complete more the next one. And this is repeated until a sprint fails. This push is kind of urge to test the team’s limits. Our experience shows that this is counter-productive. In the end, it appears that this demotivates the team as they see every future sprint as doomed.

The doomed sprint
The doomed sprint

The hectic end of a sprint during a delivery rush

When the team’s capacity is calculated to cover exactly one sprint, any delay or materialized risk is reflected by urging team members to work in a hectic rate at the end of the sprint. This leads to actually delivering less than promised due to the stress that something is going wrong. That’s why this rush at the end of the sprint should be eliminated at all cost.

Let the team deliver more by its own will

The velocity can be increased by adding a 10% of the capacity as a buffer that is used to work on tasks not included in the current sprint. Those tasks are fulfilled in Scrumban mode, i. e. from the backlog in Kanban mode during the sprint. It is used as a risk buffer and also to let the team complete its sprint (or at least the sprint goal) a couple of days before the end. Those tasks can replace a problematic task in the sprint (e.g. when there is an external dependency that threatens the sprint). The 10% capacity will be delivered extra, on top of the planned capacity and this will reflect un-materialized risk, e. g. the risk was averted. In case something goes wrong, this buffer will be exhausted, but the sprint goal and commitment will be met. This extra capacity in Scrumban mode should be monitored and if it goes to 20% for example, it means that it is time to increase the team’s velocity by 10% and still keep the 10% buffer.

Deliver early, deliver extra
Deliver early, deliver extra

Our experience shows that this is the time when employees work without pressure and contribute the most. This makes the increase of velocity possible, at the will of the team, without the urge from outside and with less stress. This way, the velocity increase is natural and desired.

The tooling

Scrumpy Planning Poker is a great tool to keep team members attention during the refinement sessions and properly estimate stories in Jira (and not only). It helps in avoiding the Big Rush at the end of the sprint and keeps estimates exact by provoking honesty in story estimations. You can start your first Scrumpy Planning Poker session right away!

Try NOW!

Tutorial

The following video shows how to integrate the Scrumpy Planning Poker application with Jira and let it edit and estimate stories on your behalf, quick and easy. Scrumpy Planning Poker saves you time!