0

I want to know about tasks analysis and estimation methods that can be used in a Scrum process to make task estimations for a sprint.

Deciding whether a story(task) is small or large requires some investigation of that story(task). And this investigation must be assigned to one team member - not to the whole team. Right? I need to organize the team's work so that they analyse the tasks (from a backlog) and provide an objective value of complexity for each task (kind of a story point) before starting a sprint. So that we can reliably estimate an amount of work we can plan for a sprint. Using the statistical method (the time spent during the previous sprint) just doesn't work good enough for us.

  • 2
    When you say random do you mean actually random (like they picked numbers at random, as good as a die roll and put those down) or do you mean something else (I would interpret the different actions very differently). Also, what leads you to believe that they are random? What is your role on the team and were you involved in estimation? – Daniel Jun 6 at 20:40
  • I don't mean that the estimations are true random numbers, but as a developer I understand that the task analysis was superficial. – embedc Jun 7 at 15:53
  • How have you determined that the estimates don't track to some reasonable confidence interval? Without more context, calling team estimates "random" sounds more like a rant than an objective observation. What's your supporting data? – Todd A. Jacobs Jun 7 at 20:34
  • What's your role in this team? You say you need to assign things and organize the team's work, which is generally something the team is supposed to do themselves. Are you a member of the team? – Erik Jun 9 at 19:37
3

Agile teams look at project work as an assignment to the collective team. Rather than working in the units of time it will take to finish each piece of work, they think about the amount of effort that will be required to complete the work, and the complexity and amount of sustained concentration it will take to produce it in a finished, tested, and workable form. For example, it may take an hour to change a tire and also an hour to rewire the fuse box in your basement, but there is a pronounced difference in the complexity and knowledge the person will need to embrace in order to finish each task to a workable, usable, stopping place. The sustained concentration and testing is much more difficult on rewiring the fuse box than merely changing a tire.

Since the team will be committing to complete this work as a single entity, it makes sense that they should also be in charge of looking at the details of what will be produced and figuring out a way to show a relationship between tasks in terms of their difficulty. Then, a relative number, usually called story points, can be assigned each task (a smaller portion of a user story) to allow the group to intel- ligently assess how much they can do in the upcoming iteration.

I am actually reading about this topic from a book titled Agile Practices for Waterfall Projects - Shifting Processes for Competitive Advantage Chapter 8 How Do Agile Teams Estimate? page 108-111 specifically reviews a few estimating processes:

  1. Fibonacci sequence
  2. Planning poker
  3. Team estimation game
  4. t-shirt sizes
  5. dog estimates

It looks like you can read the whole chapter through Google Books - best of luck.

  • 1
    What I'm looking for a way to produce reliable "story point" value for a task. Not based just on an opinion, a guess. – embedc Jun 7 at 15:55
  • 1
    @embedc how do you mean? It is all based on perception here. The measuring tool is the brain of the developer. Effort is a perceived entity. – nourdine Jun 8 at 17:49
  • When t-shirt sizing the team estimates whether a story is extra-small, small, medium, large, extra-large, or double extra-large • By removing the implied precision of numerical estimates, the team is more free to think about the effort involved in a story • An XL t-shirt is considerably larger than a XS t-shirt – Mar Jun 9 at 0:03
  • 1
    @nourdine No. The "story point" concept is about a complexity of a task, not about the perceived amount of efforts. – embedc Jun 9 at 6:31
  • @Mar Deciding whether a story(task) is small or large requires some investigation of that story(task). And this investigation must be assigned to one team member - not to the whole team. Right? I need to organize the team's work so that they analyse the tasks and provide an objective value of complexity for each task (kind of a story point) before starting a sprint. So that we can reliably estimate an amount of work we can plan for a sprint. Using the statistical method (the time spent during the previous sprint) just doesn't work good enough for us. – embedc Jun 9 at 6:43

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.