How can I help a member of a scrum team estimate better?

Question

Follow up question from here:

How to efficiently manage a Scrum team when one member is much less productive?

One of my developers is having trouble estimating his work. For the past few weeks he has committed to work, and once stuck in is not able to complete it. Burn down charts then goes out of whack.

My other developer in the team is also concerned that he is not performing.

Approaches I have taken so far:

• Using daily stand ups to deal with the impediment. I have been giving the slow developer tips; get the easy tasks out of the way then do the hard ones.

I have even explicitly asked him on 2 -3 occasions if he will complete the task in time. His attitude has been 'yeah I will do', but then on the day tell me he can't complete it.

• I have asked the developer if he needs the other resource to step in and help him. He would always say no.

I am now starting to run out of ideas on how to deal with the slow developer. I am starting to think that he does not care about respecting the burn down charts, and is carrying the attitude that it will be done, when it is done.

EDIT:

I am encouraging the team to become more cross functional. In this instance that would not have helped anyway, because the task in question has to be completed by the person who started it. Otherwise we will have too many cooks spoiling the broth.

I have also educated the developer about the business objectives, and the team velocity is what is being tracked etc Developers agree that this is the right way to deliver work, fast developer is thriving, slow one isn't.

Answer 1

TLDR: Implement shared ownership of work.

One of my developers is having trouble estimating his work.

In Scrum, there is no such thing as a single developer's work at the time of estimation. Ideally, such a concept shouldn't exist ever, with proper use of the concepts of shared ownership, pair programming, etc.

The Team owns work, and the Team estimates work. Together.

So your problem is not helping a developer estimate better. Your problem is helping the Team estimate better.

The first step towards that goal should probably be to make sure the Team is actually estimating together, as a group.

I have even explicitly asked him on 2 -3 occasions if he will complete the task in time. His attitude has been 'yeah I will do', but then on the day tell me he can't complete it.

I've come across this phenomenon a few times, and a few different things can cause it.

• The developer is afraid of being punished for not completing things on time, so they try to hide the fact that they're behind, instead just hoping they'll figure something out and the problem will go away.
  • Proposed Solution: Make sure everyone understands that the Team succeeds or fails as a whole, and that no one person will be held accountable for any specific instance of failure.
• The developer only cares about solving the problem right now, they don't care about schedules or conflicts or critical paths or any other of some such 'nonsense'. So they say whatever they can to make the PM go away so they can get back to 'real work'.
  • Proposed Solution: Educate the developer as to the business costs resulting from incorrect or insufficient estimation or information.
• The developer just simply dislikes/is bad at estimation, and so tries to avoid it as much as possible.
  • Proposed Solution: Estimating as a team should help via social influences. Combine with training or picking up of systems designed to make estimation easier, such as estimating in story points (relative work) instead of days.

You'll need to talk to the developer to determine precisely why he is avoiding proper estimation, and react accordingly. People always have their reasons for what they do. Often they're good ones.

I have asked the developer if he needs the other resource to step in and help him.

The wording you are using here seems kind of condescending to me. "Hey, I notice you're having trouble completing your work. Do you want Mr. Senior to come in and save you?" It wouldn't surprise me if he refuses, either out of annoyance or fear that he will look incompetent for accepting help on work that 'belongs to him.' Again, the solution would be to remove single-person-ownership of work. Then, the Senior isn't 'helping' with 'his work'. The Senior is just 'doing work normally.' There wouldn't even be a need to ask.

Answer 2

Do team estimations and swarm userstories:

The idea is that you get all the developers to work (swarm) on a single story, instead of having each developer working on a separate story. The goal is to get more stories fully completed. It's better to have 80% of the features 100% done, instead of having 100% of the features 80% done.

https://www.infoq.com/news/2013/02/swarming-agile-teams-deliver

Let the Team find solutions to the problem during the retrospective. Instead of you finding solutions to what you think are problems.

Ownership:

Otherwise we will have too many cooks spoiling the broth.

To many cooks? It's a team, they are the cooks. Teach the team something about collective code ownership as an Agile principle.

Collective Ownership encourages everyone to contribute new ideas to all segments of the project.

http://www.extremeprogramming.org/rules/collective.html

Other read about code ownership is this: https://martinfowler.com/bliki/CodeOwnership.html

Process:

he does not care about respecting the burn down charts

As a Scrum Master I do not care about the burn down, it is just a signal that we are behind. A trigger to discuss how we can resolve it, not to push the developers todo more. That will only result into sloppy and buggy work.

You describe as if the developer should go faster, because of the burn down. This will lead to death marches and against the sustainable peace Agile promotes.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

If you start pushing, this developer will not make the constant pace. Development goes as fast as it goes. It is done when it's done. Some are faster than others accept it. Unless the developer is deliberately slowing down and slacking what do you expect to do about it? Demotivate him even more by publicly pointing it out at the Daily Scrum?

Easy last:

get the easy tasks out of the way then do the hard ones

This also seems counter intuitive. The hard tasks have the highest uncertainty and thus risks. You should focus on those first. The earlier you know possible problems or slowdowns the better.

The easy tasks are easy, so you can postpone them to last without to much risks.

Answer 3

I am starting to think that he does not care about respecting the burn down charts

No-one respects burn down charts. it is just an indication of whether you are going to hit your deadline.

Estimates in scrum are supposed to be self correcting. If you underestimate on sprint 1 by 20%, increase your estimates by 20% for sprint 2.

It sounds like this developer is under pressure to put in low estimates. Perhaps they are just a bit slower than the others, but their effort still burns down the total. Take the focus off giving low estimates and aim for consistent estimates

Answer 4

Stop relying on Expert Estimation and start relying on Forecasting. Expert estimation, whether done in hours or story points, should be your last resort and only used when you have no historic data to base your estimates on. At least, according to Steve McConnel, author of Software Estimation: Desmystifying the Black Art, and I tend to agree with him.

People are notoriously bad at estimating. The average estimate is 2x too small. In order to get 90% confidence you need to quadruple the estimate. Todd Little - Agility, Uncertainty, and Software Project Estimation. I've reproduced those numbers with actual data from a real team I worked on. Let me repeat, in order to get 90% confidence in an estimate, you have to quadrupple a developer's estimate (mine included).

Thankfully, there are good ways to project historic performance into the future. Personally, I prefer to average Cycle Time and extrapolate from there. I've found it gives accurate, but not precise, results.

Cycle Time is the amount of time from the time work is began until the work is finished. I measure this in increments no smaller than whole days. Find the average cycle time for this developer's work. Once you have this, you can reasonably estimate how much work they can actually do in an iteration. Let's say this dev averages 1 card every 4 days and you have a 2 week (10 day) sprint. That means that the dev will, on average, complete 2.5 cards every sprint. The actual will likely be 2 or 3, but will be much more accurate than your current estimates, which are obviously off enough to cause both of you some serious distress.

Now, keep this average in mind during planning. Don't expect the dev to complete any more than their average. Stop planning for more work than your dev can accomplish. If the developer says he can do more than his average, gently remind him of what the numbers say and that you'd rather him be successful and finish early than commit to getting more done than the team can actually accomplish.

Remember, if you plan for more work than your dev team can do, that's your fault. You're the project manager, not them. Also keep in mind that these are averages. He won't complete exactly 2.5 cards every sprint. Sometimes more will get done, sometimes less, but on average 2.5 cards will get done. It needs to be safe to fail. These are estimates, not commitments or deadlines. No amount of planning or estimation will be perfect. All estimates are wrong, some are useful. What matters is that working software is delivered on a frequent basis.

Answer 5

I have even explicitly asked him on 2 -3 occasions if he will complete the task in time. His attitude has been 'yeah I will do', but then on the day tell me he can't complete it.

This doesn't sound like an estimation problem to me, in the development sense of "poor at figuring out the complexity of and effort required for a task". This sounds like it could be a very generic, "poor at turning work in on time" problem.

Have you asked him, on the day, why he wasn't able to complete it? What does he say?

Have you asked him why he routinely is unable to complete the work he has committed to? What does he say?

Try asking daily for a confidence level whether he will be done on time. Ask him to give reasons for it, and emphasize that the goal is to know early that there might be a problem. Explain up front that if he is giving you 95% confidence level up until the day he doesn't turn it in on time, he'd better be able to point to an avalanche that happened since yesterday.

Answer 6

Sounds like a team problem (or maybe a scrum master's problem), not an individual developer's problem.

In any developer's team there are differences between the team members. Some people get work done very fast, others take a bit more time. The overall team velocity should guide the estimates, not the individual developer's time.

A few countermeasures:

• Value diversity. Make sure that everyone knows their own and their teammates strengths and weaknesses (both personality-wise and with regards to skills and knowledge). Sometimes for example the fastest developer tends to be a bit sloppy when not working on challenging problems; while the slower developer does not mind doing boring tedious tasks.

• Work on better estimates from the team as a whole, by using relative estimates instead of time estimates. (Story A was 5 story points - is story B smaller or larger?). This really increases accuracy.

• More teamwork, more swarming, more pair programming, more collaboration.