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?

Improve this question
6
  • What does The Scrum Guide say? What does the Manifesto for Agile Software Development say?
    – Alan Larimer
    Commented Oct 23, 2017 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
    Commented Oct 23, 2017 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
    Commented Oct 23, 2017 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
    Commented Oct 23, 2017 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
    Commented Oct 28, 2017 at 19:27

4 Answers 4

Reset to default
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.

Improve this answer
1
  • Thought so, thanks for confirming, their burn down charts are out of whack.
    – bobo2000
    Commented Oct 23, 2017 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.

Improve this answer
-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.

Improve this answer
5
  • How do you do that then?
    – bobo2000
    Commented Oct 23, 2017 at 21:09
  • Are you assuming that people are always going to estimate accurately?
    – bobo2000
    Commented Oct 24, 2017 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
    Commented Oct 24, 2017 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
    Commented Oct 24, 2017 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
    Commented Oct 28, 2017 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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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