Stakeholders want an unfinished PBI released to the customer

The Developers are accountable for quality, not the customer, so it isn't the customer's choice to make.

The Developers are not obliged to release a darned thing if they are unhappy with the quality of the Increment they have built. Yet the professionalism which ought to be afforded to them is absent in the situation you describe. It appears that respect for their ability to decide this is missing. It seems that no-one has thought to ask them. Worse, the Developers might not even be aware of the professional accountability they have themselves. That's what really troubles me here, more than the decision of whether or not technical debt may or may not be worth incurring on this occasion.

Thanks for your reply Ian.

I have read many posts written by yourself and appreciate your experience and knowledge. 

If the Developers were aware of this via the Sprint backlog,  it's state and are in agreement that the item was not done and should not be presented or released,  but due to the way the conversation went regarding challenges at the Sprint Review, the stakeholders are still wanting it given to the customer. What should happen in this case please 🙏 . 

I know that the PO should be empowered and his / her decision should be respected by the entire organisation, but having stakeholders pressure him / her to give work not done to the customer has happened and how would a SM play their part here please?

I can't seem to find a single example of this happening when I've searched.

Ian hit the nail on the head. I'd also suggest that the result of cutting corners (e.g. technical debt) is more expensive to pay back later, and will only come back to sting the Developers later. And of course, it will impact the Product Owner from realizing value when progress slows because the technical debt wasn't handled.

What I would suggest is to make the work transparent on the Product Backlog, and if the Product Owner feels that work is the most important to complete in the next Sprint then the Developers can pull it in. By the way, when the PBIs do get finished the Increment can be released any time during the Sprint. So if it takes just one or two days to finish and get the PBIs to Done, then customers won't have to wait until the end of the Sprint.

I know that the PO should be empowered and his / her decision should be respected by the entire organisation, but having stakeholders pressure him / her to give work not done to the customer has happened and how would a SM play their part here please?

This is where Scrum Teams live by the Scrum values of courage, respect, and openness to be professional and transparent. We cannot give in to pressure - it only hurts those doing the work and makes Developers resentful as they have to clean up the mess later. A Scrum Master will coach the team on how to provide the proper message, and perhaps help the organization understand the need for empirical planning.

By the way, anyone who takes a PSM I course goes through a scenario similar to this, and learns what happens when a team is put under pressure to deliver something they cannot - it usually results in making the situation worse.

Awesome thanks Chris.

Really appreciate your replies.

Si.

Many good points  has been made already and I agree with the above. However just from a slightly different angle. Instead of interpreting the scrum-guide roles as cast in stone, have an open conversation with the developers, PO and client representative. I believe Scrum is much less prescriptive than people make it out to be. 

We had this scenario multiple times. Sometimes the incomplete work is in an area the client does not use, and they really need to complete an upgrade due to financial year budget cycle restrictions. We then release if possible and create PBIs for unfinished work. On the other hand we had scenarios were unfinished work cannot go out, as once out multiple clients will take the software and will  overwhelm the client support teams. Have the discussion and get all input from people. (The agile mindset of negotiation over contract.apply I think )

Hi Simon,



In your initial post, you mentioned both tech debt and undone work. Worth noting that these are different things.



Tech debt can be a conscious decision to implement a sub-optimal solution in order to get to market sooner or deliver some value today. Technical debt, a sub-optimal solution, could still meet the Definition of Done, despite it not being the optimal solution for the product. As a conscious decision it can be made transparent in your product backlog, be sized and discussed and addressed in the future. It is borrowing from tomorrow to gain something today. Not ideal, but can at least be made transparent.



Un-done work is far less transparent and more dangerous. Un-done implies it does not meet the definition of done; the minimal quality standards. Un-done means there are many unknowns and potential risks associated to the started but not finished work. Un-done puts future work in jeopardy and is like having a mine field in your product, and you won't know where the mines are hiding. 

@Ian and @Chris provide amazing points and offer great guidance. Combining one of Ian's quotes "The Developers are accountable for quality, not the customer, so it isn't the customer's choice to make.". and one from Chris "I'd also suggest that the result of cutting corners (e.g. technical debt) is more expensive to pay back later, and will only come back to sting the Developers later." reinforces the importance of Developers making the call. Not customers. Not Product Owner.

This is one of the situations we, real time Scrum practitioners working at the real world are facing almost daily.

The conflict between academic understanding of any matter and its practical implementation exist in any discipline, and Scrum is not an exception.

Money talks, so depending on market needs, management pressure or customers deadline, many Scrum teams often face the tough choices of breaching Scrum rules(which always has consequences) or get bankrupt, fired, or cut of funding. Most often this Scrum breaching decisions of management and clients are counter productive and even damaging(but sometimes led to successful outcome, in my experience too); but anyway - in the business environment one who pays, is  ordering the music, so this is the reality we all have to take into account

Not to talk about the damaging activities within the team, like developers missing the daily scrum, resisting Scrum or Product owner trying to act as a boss and dictator of the whole team. Or, on the contrary isn't available at all.

Important thing to understand during every such instance, when Scrum is broken,  is analyze the reasons, and try to forecast the consequences. 

In general, once the breach is forced upon the team at the commercial environment, nothing can be done to correct it, except for planning the improvement of the operations in the future... To prevent such occurrence, and correct the damage.

Stakeholders dissatisfaction and following damage (which can take multiple forms) is usually happening for reasons, and reasons are usually buried in the way the Scrum was operated in the past Sprints.

Just a few examples:

-Were previous Sprint review the working sessions where stakeholder feedback was taken into account and both Scrum team and stakeholders jointly discussed what to do next, or it was it just a presentation?

-Is the Product owner connected with stakeholders and end users, has he or she build a good relationship with them while keeping up his valid membership with a scrum team?

-If the PBI item selected for a sprint was not completed it means there was something wrong with either shaping Definition of done or whole Sprint planning. What went wrong?

-How exactly definition of done is created, and was the idea of updating Spring backlog and definition of done prior to the Sprint review, so Increment could be born and presented, considered by a Scrum team? Developers and Product owners can do at any time.

-Was the Product owner explaining PBI and Product goal clear enough at Sprint planning?

-Were there any issues about obvious bad health of Scrum team addressed at previous Sprint retrospective? if not, why? Do retrospective happen at all?

-Are the developers using best practices which they can employ? Or there some force within an organization, who is dictating them how to code, test, and complete? Distorting their work otherwise?

-Is the a pipeline built between development and operation, which is not mandatory but very recommended in Scrum?

-How the PBI, also unofficially referred to as "user stories" are created, how much end user feedback is taken into account, and how much is born purely in Product owner own mind?

Those are the factors which might have LED to this situation, which you have to address, on Retrospective. Or there can be other reasons too...

As for the consequence and solutions: considering the problem such you describe, I often harshly describe it with a cynical but true phrase:

" It's too late for ask for a good diet, when your kidney has fallen out"

What's happened, happened. Use this experience for learning in true empiric way, and remember that in Scrum every cloud has a silver linen. Every failure has its achievement.

Lesson learned, identify and fix the reasons which led to this, and things will soothe themselves out.

 Having said that, with all due respect I categorically reject the noting that developers are the one ones who ultimately decide upon quality of the released items.

This idea is good for the Scrum team who are operating on the asteroid for their own use, and reporting the results only to the scrum.org...

In any real life organization which is operating on planet Earth, especially in the commercial firms where most of us operate(lets admit it) its END USERS who determine the quality.

Developers can consider their product high quality as much as they want, if end users reject it, then the organization who is releasing the product will be filing for bankruptcy very soon. Sending developers at the job market to find new jobs.

In fact the important of the end users was stressed in the last edition of the Scrum guide, which mentioned clearly that :

A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.

Not to talk about definition of Done. Which is crafted by the Scrum team entirely only when there are no requirements of the Organization.

Otherwise 

If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. 

So when there are disagreements between stakeholders(who keep interest of their customers and market needs in mind), it only means that connection between Scrum team and Stakeholders was broken somewhere. So fix the pipeline instead of just wiping out the water. 

Fails and and mistakes happen. The importance of Scrum is to identify and fix them early, and avoid them in the future, like I wrote in the previous post. 

Brilliant points everyone,  thank you.

Si.

The push to release unfinished PBI is common but the circumstances, in which it happens can vary drastically. 

Maybe there are no technical or quality problems but the scope of the PBI is not fully realized and the PBI can be split, where the finished part meets the DoD and delivers value (it's a pit it wasn't done during the Sprint)

Or

Maybe there are important technical, and quality issues and no splitting is possible.

Maybe tomorrow's start of the Olympic Games depends on this piece of functionality.

Or

Maybe it is just yet another software drop without serious time criticality.

As the scrum masters, we help the Scrum Team and its stakeholders to gain maximum transparency through skillful facilitation, and asking powerful questions.  We educate them about Scrum so that they can understand the consequences of their decisions. We remind them about the Scrum values. We enable them to draw conclusions from their actions and constantly improve.  But it is not for us to decide what to do.

Anything else we can do? 

Unfinished PBI should not be released, It should be put back into the Product Backlog and let the PO decide what to do. 

Unfinished PBI should not be released, It should be put back into the Product Backlog and let the PO decide what to do. 

This is exactly what Scrum Guide says. In real time profit oriented business things are often bit more complicated.