Unexpected work to meet AC - new story?

What should the team do to most accurately forecast the work they believe to remain?

During the sprint it emerges that there is unexpected work to meet the acceptance criteria. The unexpected work was unforseeable during planning. The Acceptance Criteria has not changed, but there is an additional task needed in order to meet it.

Actually this is fairly common. When building complex products, we need to expect the unexpected. It is not expected that the Development Team knows everything in Sprint Planning. If they did, perhaps Scrum wouldn't be needed. And we use empiricism to help us inspect and adapt the Sprint Backlog. We also have something to provide guidance to the development team, called the Sprint Goal. 

The Sprint Backlog, which is a forecast of the work needed to meet the Sprint Goal, should emerge and change throughout the Sprint. It is not expected that the Development Team knows every task needed in Sprint Planning. The Sprint Backlog, which contains the Product Backlog items selected by the Development Team, as well as the work (i.e. tasks), is changed by the Development Team throughout the Sprint. The Development Team uses the Sprint Goal to guide them and to provide flexibility.

Hi,

Thanks for your input.

To clarify my dilema: I'm not expecting the development team to have been able to predict the unforseen task, and it's not an issue that the story will take longer to deliver than expected. It is also agreed that even though the effort required has increased, this is still the most valuable thing to work on and the story should proceed.

My question is purely about whether the original story should be closed and a new one created in light of the new effort. Some team members have a preference to 'bag' the story points on the basis that they have completed the 'tasks' that they envisaged, and that now that the effort required is better understood, there should be new PBOs brought into sprint to represent the new work.

My feeling is that since the acceptance criteria hasn't changed, there isn't a need to create new PBOs, and that the mechanism of tracking velocity through story points would be skewed if more tickets with more story points are created to meet the original Acceptance Criteria.

I'm sure it's a grey line between when it is 'new' work which warrants extra points, and when it's unexpected work which isn't new. Perhaps it is moot, but regularly seem to be stuck in a debate about 'scope creep', I'm looking for some guidance on how we can settle an endless debate on "should we create a new ticket for that?"

Thanks again.

Simon,

These are of course just my opinions/thoughts:

My question is purely about whether the original story should be closed and a new one created in light of the new effort. 

Does your DoD require an item to meet all acceptance criteria before it is closed?   If so, should the closing of the item even be up for discussion?  If not, that begs the question 'Why not?'

Some team members have a preference to 'bag' the story points on the basis that they have completed the 'tasks' that they envisaged, and that now that the effort required is better understood, there should be new PBOs brought into sprint to represent the new work.

This is reminiscent of a typical "team" approach around getting credit for work done, regardless of whether the item met DoD.   Does it matter if the team completed all of the tasks identified at the start, if there is additional item scope unaccounted for in that task list?

Two things are very important from an educational perspective: Story points should only be tallied at the end of a sprint for completed items, and story points only have value for planning purposes.   

To put another way - if every sprint forecast item is incomplete at the end of a sprint, should the team spend time figuring out how many of their predicted story points were completed?   Should they consult the customer on this, or do you think the customer couldn't care less, since they don't have anything of value at the end of the sprint?

Now, it is usually at the discretion of the Product Owner whether to accept an item that doesn't meet all of the acceptance criteria, and if so, whether the unmet acceptance criteria should be moved out into a separate item.   This is not a decision left up to the Development Team to decide.

Simon, from the Scrum Guide: 

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. When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a Sprint

As the need for more work becomes transparent to the Development Team in order to meet a given acceptance criteria it can be inspected to determine whether the the acceptance criteria can still be met within the Sprint or if this new information endangers the Sprint Goal. It could allow for important conversations with the Product Owner to happen as well. 

How might this apply to your context?

@Timothy Baffa

Thank you. Your thoughts bolster and mirror my own. Yes, the DoD includes meeting the Acceptance Critieria. Your comments remind me to discourage the points and velocity from being shared outside the development team. I conseed, without representation from the developers, I may have prejudiced the argument!

@Tony Divel

Thanks too. This is an interesting challenge. I guess the question is whether or not unexpected effort constitutes "new work" if the Acceptance Criteria has not changed.

n.b. Unexpected effort would warrant a review of the Acceptance Criteria to see if the original plan still offers a valuable ROI. For the purposes of this discussion, I'm assuming this has been undertaken, and the AC still stands, and the extra effort has been accepted as necessary.

Glad it was useful Simon. Accepting the extra effort is definitely a viable option.

On the flip side of that, there were times when I was a Product Owner where I worked with the team to split off certain acceptance criteria into it's own story which was added to the backlog based on new information discovered mid Sprint. This allowed us to still deliver value and meet the Sprint goal. This may not always been an applicable practice but it can be good practice around the concept of simplicity.