3

have a query in my mind that how the time estimation is made in sprint meeting for agile work flow? Lets say for example:

In a team there are 4 developers and the first sprint is designed for about 10 issues/tickets (in terms of JIRA). Each developer give rough estimate to every ticket and the whole sprint time is calculated about 1 week. Does the sprint time is 1 week or the total time of sprint dividing by total number of developers.

In the above case sprint time is 40 hours or 40 hours/4 developers = 10 hours ???

Which one is right???

Improve this question
2

2 Answers 2

Reset to default
5

I believe you're working backwards here, from an Agile/Sprint point of view. Generally, you decide on the length of the sprint first, as that is the "time box" the work takes place in. Sprints should be a consistent length, so that you can then accurately judge how much work can be accomplished in each sprint--even before they happen.

Once you've determined the length of the sprint, it's up to the team to decide how much they can get done during that sprint. If you decide to do 1 week sprints and the team has 4 members, that's 160 man hours.

If your team of developers think they can get 10 tickets done in that one week sprint, and that's what they commit to, then you can assume that they're saying an issue should take an average of (160 man hours / 10 issues = 16 man hours/issue. That said, some issues will be harder and some easier--that's what the developers need to figure out for you.

Improve this answer
7
  • See also: programmers.stackexchange.com/questions/149437/…
    – Matthew Flynn
    Apr 20, 2016 at 18:24
  • 1
    Agreed... Sprint durations are not calculated, they're chosen.
    – Eric King
    Apr 20, 2016 at 19:54
  • Not necessarily @EricKing. There are people out there experimenting with variable length iterations in the #NoEstimates space.
    – RubberDuck
    Apr 20, 2016 at 23:58
  • I'll take your word for it, @RubberDuck . There are probably people out there experimenting with lots of things. When variable length, calculated iterations become a 'thing', maybe I'll come back and amend my comment. :-) Until then...
    – Eric King
    Apr 21, 2016 at 0:13
  • @EricKing well... ryanripley.com/…
    – RubberDuck
    Apr 21, 2016 at 0:16
5

You aren't really supposed to use time estimations in scrum. One of the core ideas is that time estimations are at best over-specific and at worst just worthless.

You estimation story points. A story point is NOT related to time. This is often the hardest thing for people new to agile to grok. Story points combine difficulty, risk and effort into a single number. It's like t-shirt sizing (small, medium or large task) only a bit more specific.

At planning, you assign points to every story. Usually the first time out you calibrate based on older work. Something like 1=trivial story, 5 = a moderate story, 13 = a big story, 29 = a massive story. First time out, it seems arbitrary. Then you decide how many of the tasks you think you can get done, and "accept" them into the sprint. Then you code for the sprint.

At the end, you count the number of points for all the stories you actually completed. Do this over the course of multiple sprints, and you will learn your "velocity" in story points. That helps you decide how many stories you likely should accept in future sprints.

At no point in any of this process do you ever bother to see how long in hours a task took, nor do you estimate how long a task will take. On of the points of the scrum style of Agile at least is to STOP wasting time on time estimates, which are invariably wrong anyway.

Improve this answer

Your Answer

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

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