Sheepherding story points

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

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

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!

April 28, 2018February 10, 2021

The 10% scrumban rule for every sprint

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

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!

April 14, 2018February 10, 2021

The importance of 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.

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.

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

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

Tutorial

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

April 14, 2018February 10, 2021

How to correctly estimate the release deadline

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.

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.

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

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:

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

Tutorial

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

April 1, 2018July 24, 2018

Jira integration for Scrumpy Planning Poker

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.

From inside the story search box in the planning poker room, the Jira tickets can be individually selected or in bulk using 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.

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.

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.

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.

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

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.

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:

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.