Skip to main content

How to handle a story that will not be completed.

Last post 04:28 am January 16, 2021 by Soumyadeep Mishra
6 replies
05:30 am January 14, 2021

How do you mark a story that is complete but the PO decides is not quite what they want in production.  Do you spill the story and change the Acceptance Criteria? or "Cancel" it and then create a new story?  My concern is by canceling how does the team get credit for the work they did do?


11:53 pm January 14, 2021

If the Product Owner is asserting that the work is not suitable for release, then the work shouldn't be integrated and released. It's important for the Product Owner to have that ability, to ensure that the product continues to add value. If the work won't meet the needs of the stakeholders or, even worse, would negatively impact the stakeholders, it is their decision that it should not be released.

I would consider this like any Product Backlog Item that is not Done at the end of the Sprint. It can go back into the Product Backlog, be appropriately ordered, and the team and work on refining it and ensuring that it's Done per the Definition of Done and also usable by stakeholders. It could come up again in the next Sprint, or it could be held for a future Sprint in the Product Backlog.

However, there is a good opportunity to have a discussion at the Sprint Retrospective.

Why did the Product Owner realize that the work that the Developers did was not quite what they want and how far did it the work that was done deviate from those expectations? Take a good look at how the team performs Product Backlog Refinement, Sprint Planning, and then executes on the Sprint - there are a lot of points for the different members of the team, whether it's among the Developers or between the Developers and the Product Owner, to come to an understanding of what the desired outcome of a Product Backlog Item is. It seems like the Product Owner didn't accomplish one of the things that they are accountable for - "creating and clearly communicating Product Backlog Items".

I'm not sure why the team "getting credit" for work is of concern here. The work is not usable by stakeholders. Unless this work not being completed prevented the team from achieving the Sprint Goal or even completing and releasing other work, the team did something of value. The Sprint Retrospective is a good opportunity to "get credit" for what was Done and realign with the external stakeholders. There could be some bigger issues if the failure to complete a single Product Backlog Item is of concern.


02:43 am January 15, 2021

Another angle to this is to consider the Sprint Goal and how that guides decisions made by the Scrum Team. In this case, the Product Owner and Developers might collaborate and negotiate to find a creative solution that doesn't impact the Sprint Goal.

The Sprint Goal provides flexibility when the work isn't exactly what the Product Owner needs to maximize value, and may result in the Development Team changing the Sprint Backlog.

 


07:38 am January 15, 2021

How do you mark a story that is complete but the PO decides is not quite what they want in production. 

As early as you can. In lean and agile practice, inspection and adaptation should occur as closely as possible to the time and place of work being carried out.

This gives the team the best opportunity to adjust their progress so the agreed Sprint Goal commitment is met, and to thereby receive credit where credit is due.


03:45 pm January 15, 2021

My concern with your question is why did the story not being quite right only surface at the Sprint Review?  Does your Scrum Team not communicate during the Sprint?  If I were on this team, I would make sure that this be the first topic discussed during the Retrospective. 

As for this statement

My concern is by canceling how does the team get credit for the work they did do?

I cringe when I see that kind of statement.  What credit is given?  Do they get a bonus if they finish their Sprint Backlog?  Do they get a ribbon or trophy? Is there a ceremony where they are recognized publicly at the end of each Sprint? I would bet that all of the members of the Scrum Team are being paid for the work that they do.  There is an expectation of the organization giving the paycheck that they will do work that is going to be beneficial to the company. In an agile environment, everyone should believe that no one will intentionally do something to cause harm.  So why do people need to get credit for completing a single story? Isn't the success of the products being built and the impact that has on the organization that is paying you enough recognition?  Companies typically reward people based on their contributions to the organization.  A single story is not going to make a difference.  Getting products that people want to use into the hands of those people is what makes a difference.  I'll get off my soapbox now.

Back to your question.  As a Scrum Master, I would want the team to understand how this happened.  There is apparently a disconnect between what the Product Owner felt the product should do and what the Developers understood it should do.  Since the Product Owner is responsible for making sure that the Product Backlog items are well understood by all, to me this seems to be more of an issue for the Product Owner to address going forward. The team needs to find ways of validating that the understanding is the same with everyone.  I have found that it is not enough to have the Product Owner explain the need and then ask "Does everyone understand?"  to which everyone else just nods or shakes their head.  As a Scrum Master you should help them to learn better techniques for sharing and confirming understanding of information. Have Developers explain their understanding of the problem to be solved to the Product Owner.  Have the Product Owner and Developers explain the problem to be solved to you as the Scrum Master. Bring them together to actually discuss the issues and not so that one person can explain them.


10:59 pm January 15, 2021

Credit ought to be given for eliminating waste. If it turns out that a story is not required, it is best to identify and act upon that as soon as possible, to minimize the amount of waste.

Even if this is only realized after a significant amount of work was done, once it becomes apparent that doing the remainder of that work is a poor investment, people should be courageous and respectful enough to acknowledge the lessons learned and change direction accordingly.


04:28 am January 16, 2021

Excellent points of introspection provided by all! I love the way we slice and dice the problem to get to the root of it; that's why this is one of my most loved and respected Scrum forums!

Having said that, I probably can see from where @Lisette L. Fernandez is coming from. In most of the organizations that I've observed, the senior management still doesn't understand Lean/ Agile/ Scrum, least to expect the finer concepts of these. They still measure success via 'Story Points delivered versus Story Points committed'.

In this environment, when management reports get collated at a program level (collection of several teams), comparisons are bound to happen between teams that have 'delivered' consistently that they have committed for, even if that means they just split uncompleted Stories to get the credit of the 'partial' work done. However pathetic this may sound, this is the reality in which we need to operate. 

My only opinion (alongwith the brilliant opinions of the other members in this thread) would be to consistently and relentlessly work on facilitating the adoption of Scrum values and principles within the organization, however long that may take. I too work on my due share on this; haven't got much success so far, but that won't necessarily deter me in continuing to do what Scrum encourages us to do:

  • Leading, training, and coaching the organization in its Scrum adoption;
  • Planning and advising Scrum implementations within the organization;
  • Helping employees and stakeholders understand and enact an empirical approach for complex work;

 


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. For privacy concerns, we cannot allow you to post email addresses. 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.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.