How to avoid the overestimation of issues by developers

Hello,

I guess, you just simply need a decent SCRUM training.

1. What does the SCRUM Guide say about the size of the team?

2. The velocity isn't an art of challenge or something to report. It just helps the team to choose the right amount of work for the next sprint and as well helps to the PO to forecast the release dates if no changes made on the PB.

Hello MH Bakoa,

What do you mean by individual velocity? Is someone (management?) abusing the concept of velocity (a planning/forecasting tool) to evaluate developers' individual performance?

Is a group of 16 people really likely to function as a Scrum Development Team, and to develop a team-based view of its commitments and forecasts?

"they are overestimate to increase individual velocity.   How to avoid this behavior ?"

The Scrum Guide does not refer to velocity as a metric, only that the Development Team assess their capacity in some way, and make a determination on what it can complete in the upcoming sprint based on the work proposed by the Product Owner.

That said, it is critical to keep in mind that velocity is a reflective, planning metric.   It should never be used to assess team performance, either in comparison to other teams, or comparing sprints by the same team.   It is a guide to provide information on what can be achieved in the next sprint (Development Team use), and what may be achieved in the next and future sprints (Product Owner use).

Any other use of this metric is simply incorrect and potentially damaging.

And I cannot even comprehend how the term "individual velocity" has any value from a Scrum perspective.   If individual team members are more focused on what they can complete in isolation compared to other team members, you have a very serious issue on your hands in regards to Scrum adoption.   Scrum is not a competition!

Hi,

Thank you for your anwser.

First of all, because of the size of the team, we divided it into 2 of 8 people.

How we operate :

- inside the team, we define how much points each developer can release per day

- after, we sum all the points to define the team velocity

- with this velocity, by taking into account priorities defined by the product owner and issues estimations, we feed our sprint backlog with issues.

The fact is that, as every day I report on the team velocity, my boss consideres it as a productivity measure.

I told to the team that velocity is not a productivity measure, and i will expalin that to my boss.

Why are you defining how much points each developer can release per day, and use that as the team velocity? Defining developer-storypoints-per-day is wrong.

And, stop immediately with reporting the team velocity to your boss. That has no use at all.

Productivity is not measured in storypoints-per-day. Productivity is measured in adding value.

From the Scrum Glossary. I would like to emphasize especially the last part of the definition:



Velocity: an optional, but often used, indication of the average amount of Product Backlog turned into an Increment of product during a Sprint by a Scrum Team, tracked by the Development Team for use within the Scrum Team.

> "How to avoid the overestimation of issues by developers"

The short answer: They don't.

The long answer:

Do not use story points as a metric for measuring/reporting on the teams productivity. Simple as that. If there is some "boss" is constantly complaining about the lack of "done" story points, team tend to do just that: provide him more story points, so that he shuts up and lets them focus again on providing what's really important: Value, which isn't measured in story points, but an valuable product increment.

So in your example, they aren't overestimating, as story points are only there to help the team to find out what might be possible to complete during a sprint. If this works out, the estimation is fine.

Furthermore, you shouldn't measure a developers velocity. The team does the estimation, the team does the planning and the team is responsible for the work done on the sprint backlog. So there's only a team velocity.

What we actually tend to do, is asking every team member how many days they'll be off during the next sprint before planning. This way we get an idea of how many story points might be done in the next sprint compared with availability and done stories of the last couple of sprints. like 100% available = 100 Story Points. 50% available = 40 Story Points. And even this is only to give the team an input for the development team to work with when planning their sprint, not a decision to take as a rule.

Hi, 

Thank you for your replies.

Steven,

Without done stories, how to define the team velocity for the first time ?

Velocity is a reflective metric, so without a history of completed sprints, the team simply doesn't have a velocity.   Nothing really for the PO to initially base a forecast on.   The typical suggestion is that a velocity metric isn't valuable until the team has completed at least 3 sprints.

To start, simply have the team make an assessment during their first Sprint Planning on what they feel they can comfortably complete in the sprint.   Assess their forecast at the end of the sprint, adjust if needed, and repeat.   After 3 sprints, the team can begin to use their velocity as a guide to help them assess how much work to accept, and the PO can begin using it to understand how much work to offer the team for that sprint, and project how many PBI's the team may complete by a future date.

A nice way by the way to start with a new scrum team regarding estimating in story points is the team estimation game:

http://www.agilelearninglabs.com/2012/05/how-to-play-the-team-estimatio…

This way, the team gets a good feeling for story points and comparison between stories.

Hello,

Thanks for all the replies.

I have another question : in addition to the burndow chart, which kind of report the scrummaster can produce for the PO to have a good visibility on the work of the developers ?

 in addition to the burndow chart, which kind of report the scrummaster can produce for the PO to have a good visibility on the work of the developers ?

How about a 17-page document with detail on every element of the Developers work?  You'll soon realise that a 'report' in the traditional sense won't be of any value.

The Scrum Board itself provides visibility of the current Sprint.  Is this, and the plan that comes out of the Sprint Planning session, not sufficient for the PO? If not, why?

The best visibility of the work done by the developers is the sprint review. Of course this is not a report, but in the end, it's the review where the work of the developers is shown.

And if you think, the team could perform better, the retrospective is the right place to find out if this really is the case, what the reasons might be and how the team could do better. For example with the 5 Whys technique. And always keep the retrospective prime directive in mind:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

Really, the best way for the PO to inform himself about the progress of the sprint is talking to the developers. After all he is part of the Scrum Team.

Triangluation is a good technique to normalize/validate that the team is still following the same reference/baseline scale. The goal is to make sure that a 5-point story does not slowly evolve into 8 or 13 points due to external forces or other unintended factors.