How to address friction between estimation requests and delivery commitment

Question

I'm working on a large program, of which my team are a small but vital part. We have three development teams on aligned on three weekly sprint cycles. We assign stories from the backlog based on a development team's own capacity (the number of story points) which they commit to for a given sprint.

• Developers are required to report their capacity commitment for Sprint N+1 on the Thursday of the 2nd week of Sprint N.
• Developers are also required to factor into this Sprint N+1 commitment the approximate effort they will spend in estimating stories to go into future sprints.
• We have an internal mandate from management that for a story to go into sprint N+1, the estimation must be completed by the Wednesday of the final week of sprint N.
• The amount of estimation effort per sprint is highly variable, but usually between 1 and 2 days.

The problem we are seeing, which is recurring pretty much every sprint, is that the teams prioritise their sprint N delivery over the sprint N+1 estimation. This usually results in the estimation work being shoved up towards the end of sprint N. When this happens, we often do not have sufficient estimated stories in the backlog to feed Sprint N+1.

This comes up time and again in sprint retrospectives. I have approached management and suggested a solution which would involve having a separate "estimation backlog" which could be used to feed the team backlogs. However, this has been rejected.

The problem can be somewhat mitigated by getting the estimation tasks to the developers as early in the sprint cycle as possible - the earlier we get them, the more likely they are to be estimated within the deadline for inclusion in next sprint. However, this is often not possible.

I wondered if anyone could advise on a way to make this problem more manageable, or suggest a solution which I could take to management?

Answer 1

Disclaimer: I assume, based on your usage of the word 'Sprint', that you are working in Scrum. Even if you're not, you should still considering implementing a planning meeting.

TLDR: Estimate in the planning meeting.

---

First, ask yourself (and, if you don't know, upper management) why some of these mandates are in place. It may be that you can fix this problem simply by removing them.

Developers are required to deliver their capacity commitment for Sprint N+1 on the Thursday of the 2nd week of Sprint N.

Why? Locking developers into their commitments earlier than necessary seems distinctly non-Agile to me. What if requirements for those stories change? Are developers unable to remove/add commitments then?

Developers are also required to factor into this Sprint N+1 commitment the approximate effort they will spend in estimating stories to go into future sprints.

Not really a big deal, but is there a reason you don't simply reduce focus factor to account for this?

We have an internal mandate from management that for a story to go into sprint N+1, the estimation must be completed by the Wednesday of the final week of sprint N.

Same as my first point, this seems like a bad idea to me. What would be a much better idea is for a story to be Ready by Wednesday of final week. They can then estimate it in the planning meeting for sprint N+1.

the teams prioritise their sprint N delivery over the sprint N+1 estimation.

This is just natural, as developers (typically) tend to focus on development before all else. However, if you have a mandatory, scheduled planning meeting, then there's not really any wiggle room to not estimate during said meeting.

suggested a solution which would involve having a separate "estimation backlog" which could be used to feed the team backlogs.

NO. What if the estimates change?? Note that I'm not saying that estimating early is a bad thing. But if that is done, the estimations should be reviewed and changed closer to the sprint. Estimating early and then using those as commitments flies in the face of Agile.

somewhat mitigated by getting the estimation tasks to the developers as early in the sprint cycle as possible

See above; this might mitigate your current problem, but it will cause others. Don't do this.

Answer 2

Stop with the word commitment in context with estimations. One of the biggest Agile frameworks Scrum changed their text from commitment to forecast in 2011.

Software development is a highly uncertain creative process. Its done when its done, not when you said it would be done. It just doesn't work like that. This means there is also no good reason to commit to it, unless you want to pressure developers in doing overtime (which ofcourse is stupid, because they will make a mess, meaning you will go slower in the long run).

Agile cycles do estimations for different reasons:

• Long term (probably inacurate) forecasts, and only if needed
• Get discussions going around tasks and see if everyone understand the task at hand
• Giving the team a sustainable-pace

Teams should be commited to delivering a highly valuable and high quality product, but not to estimations. If managers are too focused on commitments it shows they have no clue about sustainable software development.

On a side-note I am pretty worried by your words:

This comes up time and again in sprint retrospectives. ... ... However, this has been rejected.

Rejected by whom? Management? Let the people who do the work decide how they work. Isn't that an Agile 101, read the manifesto and look for words like trust, sustainable and self-organizing: http://agilemanifesto.org/principles.html

Management should be facilitating:

The role of middle management is to see the whole and build the capability of the organization to build great products. He should help team and ScrumMaster with removing obstacles and making improvements. He should teach the team how to improve and solve problems. He should Go See to understand what is really going on in the place of work and see how he can best help the team improve their work.

Read more here: http://less.works/less/management/role_of_manager.html

In your-case you found improvements in the retrospective, but someone won't let you implement them. Sounds like a pure command-and-control situation. You should teach the organisation to embrance self-organising continuous improvement or maybe just stop trying to do Agile at all.

Answer 3

How about working with the Dev Team and the Management to assign a period of a given day (say Wednesday afternoon) in the Sprint 'N' week and dedicate that time to N+1 estimating?

Another reason for may be that the sprints are too full, so the Dev team are so worried about not being able to complete the work in 'N' sprint that the estimating becomes less of a priority.

I would suggest cutting down the items in the sprint and setting a few hours in any given day for the entire team to do the estimates for the next week. If they have time left at the end of Sprint 'N', they could always pull more items from the backlog to complete.

You'd soon find the balance of amount of work in Sprint 'N' and the amount of time needed for estimates for 'N+1'.