1

Working on a project right now that is using Scrum, the company is doing the following:

1) Working out the availability of the team based on resources available and number of hours they can commit?

So if we have 5 resources available, the total number of hours they can all commit is added up.

2) Create a sprint backlog based on the total number of hours they can commit

3) Expect resources to deliver in that amount of time.

I have suggested this is anti scrum agile since the capacity is based on the average amount of time completed in x time. i.e. only because you have 37 hours worth of resources available does not mean you can get 37 hours worth of work done. Am I correct?

  • What does The Scrum Guide say? What does the Manifesto for Agile Software Development say? – Alan Larimer Oct 23 '17 at 16:26
  • I'm curious to know why you think you can't get 37 hours worth of work done in 37 hours? – Baracus Oct 23 '17 at 19:18
  • 2
    From people not estimating 37 hours worth of work in 37 hours accurately. It's the same reason why you will never get exactly 40 hours worth of work in a 40 hour week. – bobo2000 Oct 23 '17 at 19:21
  • So the problem here is estimation. Get better at estimation and the work will fit (or rather, the work will fit as often as it doesn't fit). Hours vs Story Points vs some other measure of "size" doesn't matter if you can't estimate well. – Baracus Oct 23 '17 at 19:41
  • To break this habit, could you turn your task/story estimates into ranges? Like, story A is estimated to take between 6 and 10 hours of work, rather than 7.5 hours. Then you can't just add stories to a sprint till you get 100% resource utilization. – Bart van Ingen Schenau Oct 28 '17 at 19:27
2

You are correct, that violates many aspects of both agile and scrum.

As the commenter mentioned, you should look to the scrum guide at:

http://www.scrumguides.org/scrum-guide.html

and the agile manifesto:

http://agilemanifesto.org/ and http://agilemanifesto.org/principles.html

In particular, I'd look at the scrum guide ideas on sprint planning and the principles about sustainable development and self-organizing teams.

Most spectacularly though, this violates the value of Customer Collaboration over Contract Negotiation. It forces both the team and stakeholders into a number of rigid contracts that reduce collaboration.

  • Thought so, thanks for confirming, their burn down charts are out of whack. – bobo2000 Oct 23 '17 at 17:56
-1

It is not as it is meant to be:

The Story Points shall represent the effort necessary to fullfill a User Story. This might relate to time available but must not. Compare the Story Points with Bottles of Sweat the developer producers while finishing the story.

-1

I do not think this is against Agile principles, nor do I think it is against Scrum principles.

I am not aware of any broad rules that say you should not estimate in time, although I am sure that some frameworks have an alternative preferred method of estimation.

The problem here seems to be that the team has consistent problems in delivering what they have estimated they will be able to deliver.

Therefore, they need to improve their estimation skills, and fill their sprint with the amount of work they can actually deliver.

  • How do you do that then? – bobo2000 Oct 23 '17 at 21:09
  • Are you assuming that people are always going to estimate accurately? – bobo2000 Oct 24 '17 at 6:23
  • Obviously there is a limit to how accurate an estimate can be - but in order to have any value, your estimates need to be falling in the correct range. Bad estimation makes it impossible to build a realistic sprint commitment. A team that consistently underestimates is not estimating well. Either they need to re-base their estimates, or spend more time analysing the tasks so they have a better sense of what they are actually estimating in the first place. – Baracus Oct 24 '17 at 9:03
  • 2
    That is all good, but I doubt they will ever estimate 100% accurately, just the nature of software development, once you get stuck in there are edge cases that may appear that were not originally thought about. – bobo2000 Oct 24 '17 at 10:59
  • 1
    "Improve estimating skills" is one of the most recurring items discussed in traditional project management postmortems. It's not a "Sprint commitment" but a "forecast." Higher ordered PBIs have "more precise estimates" due to being refined to a higher level of detail, but accuracy and precision is not a healthy metric. The Scrum Guide – Alan Larimer Oct 28 '17 at 19:43
-1

You can totally do this but it will mess with your estimations (which people will sandbag to be on the safe side) and despite that things will not be delivered on time anyway.

If they really want to do things this way, one way to make things better is to do it in critical chain fashion:

  • Do aggressive estimates (i.e. ones that are at the 50th percentile)
  • Add a sizeable project buffer (a rough recommended first buffer would be 50% of the time so in your case: 18 hours)
  • Pick tasks to fill the remaining 18 hours

This way maybe this approach would be realistic but given their not very enlightened approach asking them to set aside 50% of the weekly budget seems a stretch. You could bookkeep this method on the inside of the team and sandbag your estimates to the rest of the organization to make them match the numbers.

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.