To re-estimate or not

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.

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.

> 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.

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.

> 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.

> 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.

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?

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.

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.?

Wouldn't that forecast be a case of the team estimating how much work it can take on?

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

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.

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?

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.

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?

> 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.

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.

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.

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?

> 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.

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

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?

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

Hi Boris, 

I was just discussing this topic with a Scrum team in my org. My direction is and has always been to carry over the story with the original story point allocation. Velocity will average over time, and average velocity is used for sprint capacity planning as well as Epic/Project burn down and projections. 

That said,from a capacity planning perspective I encourage folks to discuss "points remaining" in the carry over story so they account for this when planning capacity for the sprint. That is, they make take on more total story points than typical if they determine most of the work is complete for the carry over. When they complete the story, they get full credit for the work and their average velocity will reflect this. 

Regards,

Greg Thom

Agile Coach

Remember that the Product Backlog should accurately reflect the amount of work which is genuinely believed to remain. If work is not re-estimated, then that projection will degrade in quality. 

I agree with Ian on this one,

In my current place of work, there are 5 teams.  3 of them have happily switched to the "re-estimation" model where each sprint, every undone story is re-estimated in planning.  The PO can then decide whether it's worth pursuing each story based on the effort left.  Note; in some circumstances the original estimate has also increased in this scenario; due to new knowledge gained during the previous sprint (although very rarely).

The remaining 2 teams are concerned that they will appear be doing less work; and are against re-estimating.  I'm trying to convince them that they should change; but I would like it to be their decision.  Whilst I've reassured them that the points are purely for their planning, and that no-one else is using them to see "how well they are doing"; they are quite adamant.

This puts me in a difficult position as Scrum Master, do I enforce the change?

Cheers,

Steve

The remaining 2 teams are concerned that they will appear be doing less work

Appear that way to whom? If this concern is valid, might it indicate that there is a coaching opportunity to be had with stakeholders or the wider organization?

People should care about valuable work actually being delivered and released, and the lessons being learned from it. If this isn't being demonstrated clearly to the team, perhaps that's the problem to solve.

Appear that way to whom? If this concern is valid, might it indicate that there is a coaching opportunity to be had with stakeholders or the wider organization?

Yep, exactly the problem I'm currently working on :)

When they complete the story, they get full credit for the work and their average velocity will reflect this.

But this again, shows points as credits. In my opinion the best comments to take from this thread is Ian's

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.

In Scrum the *only* measure of progress is the incremental delivery of working software.

I remember a talk with a manager, 3 Sprints after the forming of a new team for a new product.

I told him the Dev Team was not yet able to reach a "done" increment (not a single PBI was done, because of the lack of integration testing), so the Velocity was clearly zero to me.

He answered me : "You are harsh, they did work hard !".

And then we had a nice conversation about what velocity is and on what the team should commit... 

Hi,

An update to my situation above; all 5 teams now re-estimate undone work each sprint.  It was achieved using a few approaches:

1) I worked with management to describe that the measure of our successful teams was in fact the done work; not how many points were completed.

2) I implemented a basic scoring system for each team (points out of 10 for % of committed work complete) I.e. 10 points if you complete 100% of what you had planned to complete, 9 for 90% etc...

3) I got agreements from the teams that we would trial it for a few sprints, and if management were happy, they’d continue.

It worked for me, and I hope that helps someone here one day.  One of the benefits I’ve seen so far, is that the teams are more engaged in getting something done before the end of a sprint to ‘get the points’ in a single sprint (previously they may have rolled it over to the next).  If they don’t complete the work, then next sprint, after we re-estimate it is likely that the effort remaining will be less, and they’ll get less points for it.  Clearly getting the points isn’t the goal here, but completing work is.

 The average velocity of the team doesn’t bounce around so much anymore either; making it easier to plan, and therefore making it more reliable to deliver.

Cheers,

Steve

I implemented a basic scoring system for each team (points out of 10 for % of committed work complete) I.e. 10 points if you complete 100% of what you had planned to complete, 9 for 90% etc...

Stephen, who is making the determination around % complete for an item?   And who is the audience for this scoring system? 

If management and the Dev Team were indeed receptive to your message about the importance of "done" work in Scrum, why would they still want a scoring system in place where they get credit for incomplete work?   

Unsure how this wasteful scoring metric supports the 7th Agile Principle: "Working software is the primary measure of progress", or the Scrum principle around developing a "Done", useable, and potentially releasable product Increment each sprint.

Perhaps I've not been very clear, we only count done items in their entirety; there is no credit for partial items.  We're measuring % complete of the whole sprint.  Only done tickets are counted, the rest are re-estimated for the next sprint.

So % complete is total of points for done tickets / total no of points committed in that sprint e.g. a team commits to 20 points, and completes 10 points = 50%.

The audience is the scrum team; they can then compare the success of this sprint to previous sprints.

Hope that clears things up.

I'm grateful for your comments in this thread Stephen since this is a topic that I have been researching based on feedback from a past assessment.

Something that I started thinking about as I read your posts was that the scoring system that you devised seems to be a substitute for the Scrum Team creating, tracking, and achieving an actual Sprint Goal.  When we encourage the Scrum Team to work on a Sprint Goal instead of completion of Sprint Backlog items we encourage the Agile Principle of maximizing the amount of work not done.  Stephanie Ockerman wrote a good article on the subject of Sprint Goals that I would encourage you to read (https://www.scrum.org/resources/blog/getting-done-creating-good-sprint-goals) as it seems like you have a desire to continually improve and support your Scrum teams and the organization.  I hope you find this helpful.

How about re-estimation of finished stories to give a more accurate history - add a more precise velocity for the sprints to come? Like, when a story is closed / Done the team evaluate how many story points they would have been given this story with the wishdom they have now?

Does it really matter, Anders? What purposes would such re-estimation serve? Do you see any waste anywhere if you were to follow this process (re-estimating finished stories)?