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 BETA!

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 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.

Jira integration for Scrumpy Planning Poker

Jira Integration

Introduction

Scrumpy Planning Poker provides an easy way to connect to Jira and Confluence. The integration includes automatically filling in story/bug/task details, placing story points on tickets when voting is complete and finally adding a comment in the story how it was estimated and what was the average estimate. Optionally, a Confluence summary page can be generated with anonymous voting information for each ticket refined during the session.

The Atlassian Plugin

The most straight-forward way to integrate with Jira and Confluence is to install the Atlassian plugin. From inside Jira using a simple shortcut, a planning poker room can be open and associated with the currently selected project board. The name of the room is the name of the Jira board. The Jira users will be mapped directly to participants and the estimating process can immediately start.

New Jira shortcuts
New Jira shortcuts

From inside the story search box in the planning poker room, the Jira tickets can be individually selected or in bulk using JQL.

Quick add/remove JQL
Quick add/remove JQL

Getting the Atlassian API token

In case installing the plugin to the Jira Cloud instance is not an option, an API token can be generated to let Scrumpy Planning Poker use Jira and Confluence on your behalf.

The information that Scrumpy Planning Poker needs

Using this API token, Scrumpy Planning Poker will be able to search tickets in Jira as you type them in the search box, automatically update the story points estimate, add comments in the ticket with a summary and finally generate a summary Confluence page.

Obtaining the API token

To get this token, navigate your browser to the Atlassian Account Management portal and log in if not yet signed in.

Atlassian Account Management
Atlassian Account Management

The next step is to select the API tokens menu on the left. This menu will take you to the next screen, where you can create a new API token. Those tokens can be revoked at any time and are not connected in any way with the master password of your account.

Atlassian API token
Atlassian API token

The final step is to press the Create API token which will generate a new API token. The token can be copied to the clipboard so that it can be easily pasted in the Scrumpy Planning Poker settings dialog box later.

Create new API token
Create new API token

After pressing the Create button, the token is ready to be entered in the Scrumpy Planning Poker settings and start using the Jira and Confluence integration.

Setting up Scrumpy Planning Poker

After the Jira site URL, the user on whose behalf the integration will happen and the API token are at hand, they can be entered in the settings page of Scrumpy Planning Poker.

Open the settings dialog box
Open the settings dialog box

When the Settings dialog box opens up, choose the Integrations tab to navigate to the settings that are specific to integrations with external applications.

Navigate to the Integrations tab
Navigate to the Integrations tab

The final step of the configuration is to fill in the Jira URL, the Username and the API token for Jira and Confluence integrations. The Jira URL is usually in the format <company>.atlassian.net or <company>.jira.com.

Filling in Jira API token
Filling in Jira API token

After the Atlassian credentials have been set up, a Confluence space can be selected to contain the summaries of the refinement sessions. For example, a brand new space called “Refinement Sessions” or “Refinement Sessions – Blockchain Team” can be created. If this is not needed, but previously set up, the X button can be used to remove the option to generate refinement session summaries.

Finally, the setup can be tested by trying to search for a Jira ticket in the search box of Scrumpy Planning Poker:

Searching for a Jira ticket
Searching for a Jira ticket

Congratulations! You can now set your Jira URL, user and API token in the Scrumpy Planning Poker’s room settings. This will allow you to search for Jira tickets, automatically fill in estimates in tickets and get a generated summary page at the end of the refinement session.

Please check this video tutorial on how you can setup Jira and Confluence integration and how you can prepare the tickets for the refinement sessions, estimate them and let Scrumpy Planning Poker automatically fill in the estimates and comments.

Let’s make refinements great again!

Scrumpy Planning Poker

Online scrum planning poker can be fun again

Thank you for choosing Scrumpy Online Planning Poker application! Together we can make the boring refinement sessions funny again. Translated into several languages, absolutely free and convenient for team collaboration and office fun, Scrumpy makes Poker Planning great again!

TRY BETA! 

What is Scrumpy Planning Poker?

Scrumpy Planning Poker is a web application which can run in your favorite web browser. It looks and feels like a native application. By installing it on the desktop with the Add To Desktop menu it will become part of your day-to-day work. It is ready to start a refinement session anytime you need it.

The application works equally well on different platforms including smartphones, tablets, laptops, desktop computers, TVs. It adapts well to the screen dimensions and makes the best use of the host device.

The Planning Poker application uses funny images and jokes for the estimations. It makes sure that your team will not get bored again during the refinement sessions. We believe that planning and refinement sessions must be fun, keep everyone involved and provoke collaboration during the estimation. Our application aims at this goal and helps you have productive meetings.

Last, but not least, we’ll be glad if you spread the word about the Scrumpy Planning Poker. Let others have fun with it too!