4

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?

  • This whole process is full of fail because of the 100% utilization fallacy implicit in the non-agile mandates. You need to educate your organization; that's part of the Scrum Master or agile coach's job. – Todd A. Jacobs Nov 17 '16 at 5:54
  • The above is true, but let's look at this another way. Agile processes require slack. Your management team is against process slack. Evangelize slack! – Todd A. Jacobs Nov 17 '16 at 5:57
6

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.

  • Thanks for your answer - I think I didn't make myself very clear - when I say they are required to commit to a delivery for the next sprint, this is only story points (not stories) committed to, and is based on their velocity and availability. However, I have taken your comments on board. – tom redfern Nov 16 '16 at 15:25
  • @Tomo What I do for that is include it in the start of the planning meeting. It takes approximately 5 minutes. I'd likewise suggest against doing it earlier, too, for the same reasons - if your team estimates they can do 50 points (since they did 50 this sprint and see no changes for next sprint), and then the next day one of your devs quits, are they required to still estimate/include 50 points in the planning meeting? If so, that's a problem. – Sarov Nov 16 '16 at 15:31
3

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.

2

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

  • Thanks for your answer. The problem is that management is completely against having set "estimation" days. Their view is that the sprint capacity commitments should already factor estimates in. Sprints are not too full, stories are assigned to the developers based on the developers own capacity commitments. The cutting down of items would not be acceptable - this is similar to having estimation tasks and a backlog, which has already been rejected by management. – tom redfern Nov 16 '16 at 13:06
  • 1
    Thanks Tomo, I suppose then the question is "why do the dev team prioritise the delivery of Sprint 'N' items over the 'N+1' Estimations"? I would guess the ramifications of not achieving Sprint N work are greater than not estimating N+1 work, which is why the estimates are routinely left. Beyond the above I don't really have any project-level suggestions, I would only recommend you keep pushing management on what you've already suggested. – Drew Nov 16 '16 at 13:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.