Forums

By posting to our forums you are agreeing to the Forum terms of use.
Updating estimates during a Sprint
Last Post 16 May 2013 05:27 PM by Charles Bradley. 5 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Ian Mitchell
Advanced Member
Advanced Member
Posts:575
Ian Mitchell

--
10 May 2013 04:31 AM
    Hi all

    Page 14 of the Scrum Guide says:

    "The Development Team modifies Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint"..."As new work is required, the Development Team adds it to the Sprint Backlog. As work is
    performed or completed, the estimated remaining work is updated."

    Perhaps there are at least two ways to interpret this:

    1) the estimates (e.g. story points) for all remaining work should be updated during the Sprint, even for those stories that have already been estimated.
    2) only the new work being brought in is estimated. The estimates for the work already planned in will not be changed. The calculation of remaining work will be based on these figures.

    The advantage of (1) is that the estimated points reflect the truth as it is currently understood. Therefore if they are written on the story cards on a Scrum board, the information radiator will be telling the truth. By the end of the Sprint they will be very close to the actuals. The disadvantage is that better estimation (and therefore analysis) during planning is potentially discouraged, since the team know they can always change the estimates as they go along.

    The advantage of (2) is that there is a clear inspect/adapt opportunity at the end of the Sprint to improve estimation (and analysis) during planning for the next Sprint. The disadvantage is that the board is less honest, because it will be showing story point estimates that do not best reflect the truth as it is currently understood.

    Many teams adopt a compromise approach whereby tasks are broken out for each user story, and only the estimates (often in hours) are updated. By the end of the Sprint the task estimates will effectively be actuals. However the story points themselves will not be amended.

    What are your opinions on the best way to update estimates during a Sprint?
    Chee-Hong Hsia
    New Member
    New Member
    Posts:62
    Chee-Hong Hsia

    --
    10 May 2013 07:46 AM
    Hi Ian,

    This is how I've interpreted the following part:

    The Development Team modifies Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint"..."As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated.


    - As new work is required = extra tasks for a specific User Story that is needed to complete the User Story.
    - As work is performed or completed, the estimated remaining work is updated = when tasks are performed or completed, modify it to which you think it is correct.

    Usually in my teams we attend to guestimate User Story relative from each other by using the Fibonacci numbers and subtasks by hours or sometimes nothing.

    I’m my opinion it doesn’t really matter whether you use time, complexity, t-shirt sizing or even nothing, in the end it’s all about completing the stories that the team had forecasted. I’ve seen teams without any indication doing extremely well and teams using time, complexity etc. fail miserably.

    Cheers, Chee-Hong

    Ed Guy
    New Member
    New Member
    Posts:3
    Ed Guy

    --
    10 May 2013 09:36 AM
    Wearing my Coach's hat I need to answer your questions by asking more questions (don't you just hate that?):
    1. What will the team gain by updating story points in the middle of a sprint?
    User Stories are measured in relatively abstract terms: points, t-shirt sizes, ideal team days, etc. Any "truth" in the measure is a reflection of the team's long-term performance (velocity) not day-to-day progress. In my experience, revising user story estimates after the sprint adds no value to the process and can introduce confusion when planning the next sprint. I'll agree with Chee-Hong that "as new work is required" refers to the tasks needed to realize User Stories. These tasks are measured in hours (a measure of "work"). The work estimates (hours remaining) are updated daily for/during the daily stand-up, so when new work (a new task) is added it is estimated. This is not a compromise: it's Scrum.

    2. Do I understand correctly that the "new work" you are adding to a sprint reflects new user stories?
    If that's the case I have only one comment: User Stories are measured in more abstract terms: points, t-shirt sizes, ideal team days, etc. Any "truth" in the measure is a reflection of the team's long-term performance (velocity) not day-to-day progress. In my experience, revising user story estimates after the sprint adds no value to the process and can introduce confusion when planning the next sprint. We don't add stories to a sprint in progress.
    Chee-Hong Hsia
    New Member
    New Member
    Posts:62
    Chee-Hong Hsia

    --
    10 May 2013 10:01 AM
    The cool thing about relative estimation is that it will autocorrect itself when you apply it within an iterative process.

    A couple months ago I did I small research on relative estimations and it’s quite interesting to see what happens with initial estimations and how that affects the planning.
    After my research I go into the Sprint Planning Meetings with a whole other intention :D

    http://relativecomplexitytheory.blo...-user.html

    alicemenezes
    New Member
    New Member
    Posts:39
    alicemenezes

    --
    15 May 2013 06:40 AM
    But who is responsible for updating the estimates during a sprint?

    http://www.agiledistributed.com/
    Charles Bradley
    Basic Member
    Basic Member
    Posts:212
    Charles Bradley

    --
    16 May 2013 05:27 PM
    Ian, responding to your original question. Btw, thank you for all of your contributions to the forums -- I find your posts to be very informed and informative too.

    Scrum and the Scrum Guide does not really speak directly "on point" on this subject, so you know what that means... ;-)
    You are not authorized to post a reply.


    Feedback