Story not concluded

Why not re-estimate the item to reflect the amount of work which is genuinely thought to remain? What advantage would you hope to have in making forecasts using outdated or incorrect data?

Hi, Ian.

I think, If I re-estimate the item, it won´t reflect the real situation about the work. For exemplo, my story have 5 points in the actual Sprint. 

The next Sprint I re-estimate for 2 points (because I already worked 3 points). In the end, we will have a story with 2 points, not 5. But the team, worked 5 points.

This situation, will reflect in my velocity graph and  to understand the capacity of team.

What do think about it?

Thanks

Janaina - You have to think of velocity in terms of "Done" by Sprint.  Velocity tells you the amount of "Done" Product Backlog can be turned into an Increment during a Sprint.  In the prior Sprint the 5 pointer in the prior Sprint wasn't "Done", so those points are not included in velocity.  In the current Sprint 2 points were "Done", not 5 points in the Sprint.  The key is "by Sprint".

Chris

Hi Chris.

I think, this is the question: Is It true to consider 2 points as finished, when 5 points were actually used? In terms of effort.

Velocity report is correctly, it´s OK! 

For one way, I should change the points reflecting the real effort in my actual Sprint, but for another one, I should not, because is not true that I used just 2 points, I worked 5 points at the story.

Maybe, before I complete my Sprint, I reduce the points to 3, and finish the story. I make a copy to this story with 2 points and carry to the next Sprint.

But, I don´t know if my PO will agree in finished a story not finished yet. :)

Janaina,

Story points are designed to measure the complexity and difficulty of completing a task.  They are not meant to be used to measure of work performed.  Scrum does not have a "definition of partially done" that we can leverage.

I worked 5 points at the story.

If you claim to have earned 5 points on a 5 point story, it should be done and you should have a finished unit of work to show for it.  If you don't, then you should not add 5 points to your velocity chart, because you didn't earn 5 points.

Maybe, before I complete my Sprint, I reduce the points to 3, and finish the story. I make a copy to this story with 2 points and carry to the next Sprint.

I don't personally see anything wrong with estimating a task at 5 points, determining you did roughly 60% of the work, and rewarding yourself with 3 story points as partial credit.

I also don't see anything wrong with estimating a task at 5 points, determining you did roughly 60% of the work, and earning 0 points because the work is incomplete.

What I am concerned about is how you decided the work was 60% done, and not 40% or 25% complete.

It’s more important to release valuable increments than to be story point accountants. As long as the team can estimate how much work they can take on and complete in the next Sprint, then the purpose of estimation has been served. The ability to partially complete work has no bearing on this, and so it ought not to figure into velocity calculations. Where work has been partially completed it should be re-estimated on the Product Backlog, and the toral amount of work thought to remain will be adjusted accordingly.

I agree with what Ian said.

I think it's also worth considering that if a 5 point story was not completed, it could be because the original estimate was wrong. If it is re-estimated, perhaps the new estimate will be higher (trying to work out how much work was done so far will potentially get in the way of genuine re-estimation). The end of the Sprint is a good opportunity to make use of lessons learned and work out whether the estimate for the remaining work means it makes sense to carry on now, later, or just abandon the feature altogether, in favour of something more valuable.

Another thing to add is that the Scrum Team  should understand there is no value in work done. The value comes from what they deliver. So perhaps if the team feels the frustration of not delivering stories of 5 points, they will find a way to break them down in to smaller stories that each deliver at least part of the final value, and give users the chance to provide some feedback sooner.

Hi Janaina, 

In my opinion, if the team could not finish the story of 5 points in previous sprint. we keep it as it is and move to the next sprint. And velocity will be counted in the next sprint. 

We should not adjust the story point of "undone" tickets in previous sprint. If there is something wrong with the estimation, This is also a good lesson learn for the team.

Regards, 

Chi Bui.

The most important thing is what the team have learnt from a 5 point story remaining unfinished. Does it mean that 5 point stories are too big for your sprint timebox? Should future 5 point stories be re-assessed and broken down into smaller pieces, so not to run the risk again?

Also, the Product Owner should assess where the story is, and decide if there is value in continuing with the story, or move onto something else. If it should continue, who benefits from the points being adjusted? Understanding the remaining work, and the size of that may be enough for the team.

If average velocity is measured to guide the team in planning, think about how re-estimating the work and potentially “losing points” will impact that average.

In my opinion, if the team could not finish the story of 5 points in previous sprint. we keep it as it is and move to the next sprint. And velocity will be counted in the next sprint. 

We should not adjust the story point of "undone" tickets in previous sprint. 

Chi Bui,

Story Points are strictly a planning metric to be used by the Development Team and the Product Owner to assess what can realistically and comfortably be achieved in the upcoming sprint(s).

Therefore, always maintaining the same estimation value for unfinished items defeats this purpose, as you incur additional effort and complexity when planning (i.e. - this story is a "5", but not really a "5", since we did a good portion of it last sprint, etc).   Allowing teams to preserve original estimates when they are not reflective of remaining work is a back-door way of rewarding the team for unfinished items, which is frowned upon in Scrum.

All PBI estimates in a sprint offer should be re-examined by the Development Team for accuracy, so that they can assess the offer against available guidelines like team capacity and team velocity.

Once the sprint begins, story points are meaningless.   The Development Team has their forecast, their Sprint Goal, and the agreed-to prioritization of work.   Nothing more is needed.

Hi everyone!!

First of all, thanks for help me!!

To explain better this situation, the team did a correctly estimative, but we had a problem in one server that blocked us to finished the work.

The least part of work couldn't not be finished in prior sprint, so in the next sprint I reduced the point of 5 to 2.

But, in the story comment, I wrote the original point (5). I was worried about the references for the team and PO in the future. 

Team:

When they need to consult a effort about similar items, we will have 2 points and not 5, for example, so they would confused, but to resolve that, I think that its not good consider points to a new story in relation another one. Each story is a new story, and we will have the comments, if necessary.

PO:

But, PO can question us about points, "Ohh, Why this is 5, while other similar in last Sprint was 2 points?". To resolve that, I wrote a commentary about last point attributed to a story.

Hi Janaina,

Is it possible to split the story into two parts, one reflecting the part which is done, and another for the part which needs to be done? Then you can assign 3 points for the done part and can assign 2 for the part which is yet to be done. 

This way, the main story will have 5 story points, with two sub-stories which have 3 and 2 points each. 

--Anoop

Is it possible to split the story into two parts, one reflecting the part which is done, and another for the part which needs to be done? Then you can assign 3 points for the done part and can assign 2 for the part which is yet to be done. 

This way, the main story will have 5 story points, with two sub-stories which have 3 and 2 points each. 

Anoop,

It may be an option to split the story further than it originally was, seeing as it was 5 points to begin with; however, this should only be an option if each of the resulting stories delivered value to the business/customer, and did not represent a vertical split, or a split based solely on what the team finished versus the remaining story work.

Story points (and story splitting) should never be used to represent credit for completed work.   Trying to credit a team for completed work this way is a misguided approach at best to a number of other issues the team should be addressing.

The team failed to complete a 5-point story.   Have the team not only "own" the failure, but discuss what the team may be able to do in the future to mitigate such occurrences from happening again:

• Was the story too large to complete in the sprint?   If so, what can the team change to avoid a similar situation?
• Was their sprint forecast too large?   How can the team improve their ability to gauge how much work they can complete in a sprint?
• Was the story not completed due to a dependency on another team?   What can the team do to avoid such in-sprint dependencies going forward?
• Was the story incomplete due to other "blockers"?   What can be done to mitigate such blockers in the future?

It may be an option to split the story further than it originally was, seeing as it was 5 points to begin with; however, this should only be an option if each of the resulting stories delivered value to the business/customer, and did not represent a vertical split, or a split based solely on what the team finished versus the remaining story work.

Story points (and story splitting) should never be used to represent credit for completed work.   Trying to credit a team for completed work this way is a misguided approach at best to a number of other issues the team should be addressing.

Hi Tim, 

Thank you - your explanation makes really clear why we should not split the story to show how much work was done.

However, I think I was not really clear. What I suggested was, keep the 5 point story, but create two sub-stories under it - 1 with 3 points, which denotes the work done, and one with 2 points, which indicates the work which is yet to be done. If we keep the 5 points main story incomplete and move to next sprint, but move one sub-story to done - will it not solve the issue faced by OP? 

Or, is it also against the spirit of Scrum?

--Anoop

I think I was not really clear. What I suggested was, keep the 5 point story, but create two sub-stories under it - 1 with 3 points, which denotes the work done, and one with 2 points, which indicates the work which is yet to be done. If we keep the 5 points main story incomplete and move to next sprint, but move one sub-story to done - will it not solve the issue faced by OP? 

Would those two stories still satisfy the INVEST criteria, particularly with regard to each of them being independently valuable?

Would those two stories still satisfy the INVEST criteria, particularly with regard to each of them being independently valuable?

I thought INVEST was applicable only to PBI. Do the sub stories also need to satisfy INVEST criteria?

My team usually add sub-stories to each PBIs, to break down the story to sub-stories which cannot be independently delivered but gives more granularity and visibility to the tasks involved in getting the story done.

--Anoop

My team usually add sub-stories to each PBIs, to break down the story to sub-stories which cannot be independently delivered but gives more granularity and visibility to the tasks involved in getting the story done.

Perhaps this additional "sub-story" layer helps the team with item visibility and granularity.   However, if the sub-stories cannot be separated, won't attempting to treat them as separable obscure the issue of the main (true) story being incomplete?   How should the sub-stories be treated if neither of them can satisfy the Definition of Done? 

 However, if the sub-stories cannot be separated, won't attempting to treat them as separable obscure the issue of the main (true) story being incomplete?   How should the sub-stories be treated if neither of them can satisfy the Definition of Done? 

The Defenition of Done is always attached to the story. A story is never marked complete if there is an open sub-story.

Where it has helped us is to give visibility to the exact problem which holds a story from complete, and to give a picture of how much progress we have made in the story. 

--Anoop

HI Janaina, 

I totally understand your situation as in many sprints stories may be left undone when we  have external depedencies and environmental issues like server failure and network being down , the best way forward as described by some SM's earlier is   to re-estimate it in the product backlog  and then take it into the next sprint , you should not worry about losing accountabiltiy (points) of  what you devloped in last sprint as the team works towards delivering an increment which gives value not just points . 

I thought INVEST was applicable only to PBI. Do the sub stories also need to satisfy INVEST criteria?

Have you created a separate item type to sidestep the INVEST criteria?

I have never heard of the concept of a "sub-story" before.   Many of my teams have identified tasks needed to complete a story, much like you've explained where completion of sub-stories are needed to finish a story.   

Unsure why you feel the need for an extra layer between the item and the underlying tasks for visibility.   Task definition alone should give you both a measure of progress towards item completion, and transparency into any issues impeding an item from being finished.

I have never heard of the concept of a "sub-story" before.   Many of my teams have identified tasks needed to complete a story, much like you've explained where completion of sub-stories are needed to finish a story.   

Hi Tim,

Sub-Story = Tasks. We call them sub-stories, but in effect, they are tasks created to achieve the story. I think the problem was that we are using non-standard terminology. Another point for improvement identified, thank you.

--Anoop