Forums

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. If you have left the first and last name fields blank on your member profile, your email address will be displayed instead.

All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

To re-estimate or not
Last Post 17 May 2016 10:43 PM by Boris Kazarez. 23 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Pablo Rossi
Basic Member
Basic Member
Posts:173
Pablo Rossi

--
26 Mar 2014 01:33 AM
    Hi,

    I know there are many discussions regarding re-estimating stories that are unfinished. Note that I’m not talking about untouched stories, but stories that are like 90% “finished”.

    Clearly the story goes back to the backlog, but does the team re-estimate it or doesn’t tough the estimation?

    I’ve been following another similar thread, but that thread is rather old so I’m curious in what you guys think of it today.
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1535
    Ian Mitchell

    --
    26 Mar 2014 02:31 AM
    The Development Team should re-estimate the story to indicate how much work is likely to remain. If this means that the story is estimated to be of a smaller size, we can expect that the total size of the Product Backlog (i.e. work left to do) will be reduced accordingly.
    Chee-Hong Hsia
    New Member
    New Member
    Posts:73
    Chee-Hong Hsia

    --
    26 Mar 2014 03:32 AM
    Hi Ian,

    Should the team be awarded for their effort? I believe that the team should only earn the points if they deliver value, so I wouldn’t re-estimate it UNLESS that specific story can be split up afterwards in order to add value to the project.
    From my experience, most of the time the team tells me that it isn’t possible to split the items up, so the reality will be that they’ve earned 0 points for this story.
    But no panic, usually they will easily earn this point in the next sprint where the average point will be taken.

    Personally re-estimation feels a bit odd for me because then you are assuming that what has been done is actually approved and we all know that strange things can happen even when you are 90% done and the last part is for example testing.
    Of course during the sprint planning meeting, we do take into account that some stories aren’t the same size anymore as they were initially estimated so we attend to take more into the sprint.


    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1535
    Ian Mitchell

    --
    26 Mar 2014 05:51 AM
    > Should the team be awarded for their effort? I believe that the
    > team should only earn the points if they deliver value

    In Scrum nobody "earns" points as the points themselves have no value. The only purpose they have is to help teams gauge how much work they can take on, and to inform a Product Owner of how much work is likely to remain.

    This means that when work is done on a story in a Sprint, but the story is not completed and cannot be delivered, no points will count to the velocity of that Sprint. What will happen is that when the undone work is re-estimated, the total size of the Product Backlog will most likely be reduced. By definition this means that less work remains than before, and so the Product Owner can be satisfied that progress has been made.

    > re-estimation feels a bit odd for me because then you are assuming
    > that what has been done is actually approved

    No, there is no such assumption at all. Re-estimation of partially done work just reduces the size of the Product Backlog (assuming nothing else has been added in the meanwhile). The re-estimation of work remaining is a measure in its own right. It has *nothing* to do with whether or not any work has been accepted.
    Chee-Hong Hsia
    New Member
    New Member
    Posts:73
    Chee-Hong Hsia

    --
    26 Mar 2014 06:42 AM

    Posted By Ian Mitchell on 26 Mar 2014 10:51 AM
    > Should the team be awarded for their effort? I believe that the
    > team should only earn the points if they deliver value

    In Scrum nobody "earns" points as the points themselves have no value. The only purpose they have is to help teams gauge how much work they can take on, and to inform a Product Owner of how much work is likely to remain.

    I agree that points itself has no value, but when items are added in the sprint backlog and therefore owned by the team, these points naturally becomes the teams objectives. That’s the game the teams “plays”.


    This means that when work is done on a story in a Sprint, but the story is not completed and cannot be delivered, no points will count to the velocity of that Sprint. What will happen is that when the undone work is re-estimated, the total size of the Product Backlog will most likely be reduced. By definition this means that less work remains than before, and so the Product Owner can be satisfied that progress has been made.

    Taking an incomplete story and re-estimate the story gives the story a false sense of security and make it look like you have a stable velocity reduces transparency and hides the truth of what you can actually achieve from your product owner, your stakeholders and most importantly yourselves.

    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1535
    Ian Mitchell

    --
    26 Mar 2014 06:48 AM
    > By definition this means that less work remains than before, and so the Product Owner
    > can be satisfied that progress has been made.

    Apologies, I should be more clear. The Product Owner can be satisfied that less work is thought to remain...and that's as far as any satisfaction will go.

    In Scrum the *only* measure of progress is the incremental delivery of working software.
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1535
    Ian Mitchell

    --
    26 Mar 2014 06:58 AM
    > when items are added in the sprint backlog and therefore owned by the team,
    > these points naturally becomes the teams objectives. That’s the game the teams “plays”

    I've seen that game played as well, but it isn't Scrum. The delivery of points should *never* be a team's objective. The delivery of increments of working software is the only thing worth aiming for, and each Sprint Goal should express the anticipated value.

    > Taking an incomplete story and re-estimate the story gives the story a false sense of
    > security and make it look like you have a stable velocity reduces transparency ...

    No, because no points should be recorded against a Sprint for undelivered work. There is no partial credit. The expected velocity is likely to dip as a result and this, along with a reduced burn rate, can be visible to all.
    Pablo Rossi
    Basic Member
    Basic Member
    Posts:173
    Pablo Rossi

    --
    12 May 2016 02:18 PM

    No, because no points should be recorded against a Sprint for undelivered work. There is no partial credit. The expected velocity is likely to dip as a result and this, along with a reduced burn rate, can be visible to all.


    What happens with the 'Story Point' if the story eventually gets finished?

    For example:
    - Story is initially estimated at 5 points.
    - Story doesn't get finished so goes back to backlog
    - Story is re-estimated, now it is 2 points.
    - Story goes into the new Sprint
    - Story gets finished in the new Sprint
    - Does the team gets 5 or 2 points?




    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1535
    Ian Mitchell

    --
    12 May 2016 09:22 PM
    2 points would count towards the velocity, because that would reflect the size of the item that was completed during the Sprint.

    Remember though that in Scrum a team doesn't "get" any story points at all. They are not a reward nor do they evidence the delivery of value. They are simply a means to help a team estimate how much work it can take on.
    Pablo Rossi
    Basic Member
    Basic Member
    Posts:173
    Pablo Rossi

    --
    12 May 2016 10:00 PM

    Posted By Ian Mitchell on 13 May 2016 02:22 AM
    2 points would count towards the velocity, because that would reflect the size of the item that was completed during the Sprint.

    Thanks for your explanation.


    Remember though that in Scrum a team doesn't "get" any story points at all. They are not a reward nor do they evidence the delivery of value. They are simply a means to help a team estimate how much work it can take on.

    I agree, but there are also many companies still in their Agile transition. Therefore some form of planning (forecast) is needed so that project budgets can be addressed.
    How does Scrum typically work here?

    For example: before a project can start, an initial forecast needs to be provided. How is this done if we don’t take velocity into account.
    Or if the stakeholders demand from the PO to at least forecast what will come in the upcoming 2 sprints so that it can be communicated towards marketing etc.?


    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1535
    Ian Mitchell

    --
    12 May 2016 10:06 PM
    Wouldn't that forecast be a case of the team estimating how much work it can take on?
    Pablo Rossi
    Basic Member
    Basic Member
    Posts:173
    Pablo Rossi

    --
    12 May 2016 10:15 PM

    Posted By Ian Mitchell on 13 May 2016 03:06 AM
    Wouldn't that forecast be a case of the team estimating how much work it can take on?

    No idea? A team can forecast what they can take on in the upcoming sprint, but not 2 or 3 sprints ahead
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1535
    Ian Mitchell

    --
    12 May 2016 11:35 PM
    Development Team members are *accountable* for the quality of the Sprint forecast they make. They wholly own the Sprint Backlog.

    They are also responsible for estimating the work on the Product Backlog. However, this does not mean they are accountable for any forecasts made using this data and the velocity they may evidence. This is because they don't own the Product Backlog....the Product Owner does. The Development Team are not therefore in a position to forecast any part of the Product Backlog for delivery other than that part which is planned into their current Sprint. The data they provide can help the PO to make a long-range forecast, but the PO would be accountable for any such forecasts made.
    Pablo Rossi
    Basic Member
    Basic Member
    Posts:173
    Pablo Rossi

    --
    13 May 2016 12:48 AM

    They are also responsible for estimating the work on the Product Backlog.

    By estimating I assume you mean 'providing estimates'. Common practice such as using Story Points?


    However, this does not mean they are accountable for any forecasts made using this data and the velocity they may evidence. This is because they don't own the Product Backlog....the Product Owner does.
    The Development Team are not therefore in a position to forecast any part of the Product Backlog for delivery other than that part which is planned into their current Sprint. The data they provide can help the PO to make a long-range forecast, but the PO would be accountable for any such forecasts made.

    How can the PO come up with this forecast?
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1535
    Ian Mitchell

    --
    13 May 2016 01:26 AM
    It may be as simple as totalling the estimates (e.g. story points) in a Product Backlog and dividing by the best available measure of velocity. A Development Team can collaborate with a PO in order to provide those figures. They can provide estimates, given the current state of the backlog, of what might be delivered when. However they are not in a position to turn that into a forecast for delivery, since they don't own that backlog. Only the PO can make such a forecast, even where critical data in support of it is provided by the Development Team. If the PO does not have confidence in the data then a forecast should not be derived from it.
    Pablo Rossi
    Basic Member
    Basic Member
    Posts:173
    Pablo Rossi

    --
    13 May 2016 03:52 AM
    It may be as simple as totalling the estimates (e.g. story points) in a Product Backlog and dividing by the best available measure of velocity. A Development Team can collaborate with a PO in order to provide those figures. They can provide estimates, given the current state of the backlog, of what might be delivered when. However they are not in a position to turn that into a forecast for delivery, since they don't own that backlog. Only the PO can make such a forecast, even where critical data in support of it is provided by the Development Team. If the PO does not have confidence in the data then a forecast should not be derived from it.


    What if the PO has no confidence in the data and therefore cannot derive a forecast, but is forced by a manager/stakeholder/budget holder?
    I work in a company where everything is still (unfortunately) very project driven so before we can work on a project a high-level forecast needs to be provided.
    If I understand you correctly, then perhaps “totaling the estimates (e.g. story points) in a Product Backlog and dividing by the best available measure of velocity” is a common practice?
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1535
    Ian Mitchell

    --
    13 May 2016 08:27 AM
    > What if the PO has no confidence in the data
    > and therefore cannot derive a forecast, but is
    > forced by a manager/stakeholder/budget holder?

    Do you think that "forcing" the PO to deliver a forecast he or she has no confidence in would be a valid application of Scrum?

    > If I understand you correctly, then perhaps
    > “totaling the estimates (e.g. story points) in a
    > Product Backlog and dividing by the best
    > available measure of velocity” is a common practice?

    It's a fairly common way of roughly estimating how many sprints will be needed to exhaust the Product Backlog as it currently stands.
    Jason Knight
    New Member
    New Member
    Posts:26
    Jason Knight

    --
    13 May 2016 01:07 PM
    I agree with Ian on this one. The whole point of a Sprint is to have high-quality, releasable software i.e. the primary measure of progress is working software.

    Velocity is done best as a measure of the software increments added to the Product increment such that the whole Product Increment is fully usable and releasable.

    Failure to re-estimate is a subtle but important deviation; it reduces the transparency of the amount of "Done" software increment that can be added each Sprint as it spreads the process of completing work across multiple Sprints. This makes forecasting the "Done" software increment for the next Sprint harder and more error prone leading to increased difficulty for the Product Owner to plan the actual release of the software.

    For organizations in transition, this can be a difficult change to make. I have seen this go really wrong. If velocity is looked at in terms of "time spent" then re-estimation doesn't make sense i.e. the "time spent" doesn't go away if work is un "Done" at Sprint end, so don't re-estimate. Encouraging this view can lead to really bad things like building story points into customer contracts to take the place of more tradition time estimates (yikes). This is a world of hurt you do not want to know.

    Ideally, velocity is measured in terms of the Value generated by the teams each Sprint. Effort is a circumstantial metric that does not guarantee any benefit to the organization; however, measuring the actual impact i.e. value obtained in the market is a direct metric that management should actually care about measuring.

    Separating the circumstantial e.g. effort, story points, cheese its from the direct e.g. value, market share, revenue frees the team to use the effort of each PBI as Scrum intends: create forecasts that are helpful to a development team self-organizing to meet business goals the value of which the Product Owner is responsible for maximizing.
    Pablo Rossi
    Basic Member
    Basic Member
    Posts:173
    Pablo Rossi

    --
    14 May 2016 01:53 AM

    Do you think that "forcing" the PO to deliver a forecast he or she has no confidence in would be a valid application of Scrum?

    No of course not, I agree with you 100%. But lets be realistic, in most organisations everything is still deadline/budget tradition project management driven. And in these organisations, forecast is needed/forced before a project will start. Again, I'm 100% agreeing with you, but I'm just wondering how scrum fits in.
    Pablo Rossi
    Basic Member
    Basic Member
    Posts:173
    Pablo Rossi

    --
    14 May 2016 04:24 AM

    Posted By Jason Knight on 13 May 2016 06:07 PM
    I agree with Ian on this one. The whole point of a Sprint is to have high-quality, releasable software i.e. the primary measure of progress is working software.

    Velocity is done best as a measure of the software increments added to the Product increment such that the whole Product Increment is fully usable and releasable.

    If you work in an organisation still in the middle of their transition, they will say "good story but in this company/project we need a forecast/planning in able to get a budget".
    Working software is indeed the best measurement, but in most organisation, before you can start on producing working software, budget is needed


    For organizations in transition, this can be a difficult change to make. I have seen this go really wrong. If velocity is looked at in terms of "time spent" then re-estimation doesn't make sense i.e. the "time spent" doesn't go away if work is un "Done" at Sprint end, so don't re-estimate. Encouraging this view can lead to really bad things like building story points into customer contracts to take the place of more tradition time estimates (yikes). This is a world of hurt you do not want to know.

    What would you suggest?

    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1535
    Ian Mitchell

    --
    14 May 2016 05:06 AM
    > But lets be realistic, in most organisations
    > everything is still deadline/budget tradition
    > project management driven. And in these
    > organisations, forecast is needed/forced
    > before a project will start. Again, I'm 100%
    > agreeing with you, but I'm just wondering how
    > scrum fits in.

    My advice is not to expect Scrum to "fit in" with the current reality of an organization. Rather, the organization must fit in with the reality of the need for change.

    Scrum is meant to be transformational in that regard. With respect to budgeting, it's therefore up to the organization to decide how it is going to revise its financing so as to best implement the framework.
    Pablo Rossi
    Basic Member
    Basic Member
    Posts:173
    Pablo Rossi

    --
    14 May 2016 10:13 PM

    My advice is not to expect Scrum to "fit in" with the current reality of an organization. Rather, the organization must fit in with the reality of the need for change.

    Scrum is meant to be transformational in that regard. With respect to budgeting, it's therefore up to the organization to decide how it is going to revise its financing so as to best implement the framework.


    I guess this is one of the main "problem" I see happening a lot. Yes I agree that organisations must fit with the reality of the need for change and it is up to the organisation do decide how it going to revise its financing in order to implement scrum. But when I am are on a job interview and the interviewer does not fully understand scrum and the changes that will affects his company, he/she will probably not hire me because there is this false illusion that scrum provides reliable project planning.

    In most organisations that I have consulted, I see scrum masters being pushed in the role of project manager. Accountable for coming up with planning based on velocities and also accountable for enhancing this velocity. Bad idea but it happens unfortunately


    Timothy Baffa
    Basic Member
    Basic Member
    Posts:178
    Timothy Baffa

    --
    16 May 2016 05:28 AM
    Bad Scrum happens everywhere. That does not mean that a Scrum Master should conform to current organizational practices that run counter to Scrum.

    I have been asked plenty of times to behave like a traditional project manager, help with estimating, track "projects" along traditional Gantt forecasts, identify work with specific team members, count the number of "resources" working per sprint (as if increasing the head count would increase productivity, as opposed to the real impact of decreasing productivity).

    I have refused to play along. It has not been a belligerent refusal; instead, I have stated my case complete with the negative aspects of current practices, and ways to approach such goals more collaboratively and dynamically.

    Looking at your example, I would ask how often their project "forecasts" are accurate? I once worked in a company where they made such yearlong forecasts, but knew when they were making them that they were wrong, but kept that information to themselves. The goal was just to give management what they wanted to hear, and what they were used to seeing.

    When I asked them why they continued wasting such time and effort on such forecasts that they knew were BS, all I got in return were blank stares and uncomfortable laughter.

    I love the quote from Dwight Eisenhower, "I have always found that plans are useless, but planning is indispensable."

    Do they understand the folly of adhering to an imperfect plan constructed when they know [uas little as they ever will know about the project they are about to embark on? What are they looking to gain by adopting Scrum? What in their minds are they really changing?

    Sometimes, the organization listens to what I have to say. Sometimes, the organization plods ahead with others to fill their "PM" requirements. Sometimes they insist that I conform. Then it is again my decision to stay or leave. What are the prospects of effecting positive organizational change, even if it in small increments?

    Bottom line - do you really want to work in a company that really is only interested in SINO (Scrum In Name Only), and is really just looking for someone to fill in a Project Manager role?
    Boris Kazarez
    New Member
    New Member
    Posts:8
    Boris Kazarez

    --
    17 May 2016 10:43 PM
    Hi all,

    I know it's a chewed up subject, but I wonder if there are new opinions about re-estimating unfinished work since the original post in 2014.

    For me, velocity is more a rate of value delivery not the effort, so I prefer not to re-estimate. On average, over a number of sprints the velocity figures will average out in any case. Also the SP is a measure of complexity of a story and it is weird and counter intuitive for the team to re-estimate a partially completed story which can also hurt the team's reference stories "calibration". Lastly, I see estimation as a waste in terms of lean thinking, since estimating work doesn't produce real value, and therefore should be either brought to a minimum or avoided altogether (counting stories, #noestimates).

    Anyway, velocity is a team metric that should help the team to forecast what they can accomplish in a sprint, and what's important is not the SPs but the actual produced value (done increment). So given the two options, whatever makes the team more comfortable to forecast the size of their Sprint backlog should be fine, as long as it's not compromising the transparency of their work and is a consistent behavior.

    Would be happy to hear more opinions.

    Thanks,
    Boris
    You are not authorized to post a reply.


    Feedback