Sprint Backlog Items Not ready for Production Release

Key would be your agreement with your Product Owner and the time you realize that some items are not releasable.

1) If you are near the end of the sprint and you dedicated to deliver the screens, but realize you can’t populate them, you should renegotiate the scope with the PO. Most logical would be to not include the unfinished items in the increment. Re-estimate the remaining work and include them in the next sprint.

2) If you are before the start of the sprint, you might agree with the PO to deliver the screen layout in one sprint and then deliver the population of the fields. However, screen layout without functionality is not working software. And from a process point of view this is water-falling. Also, the PO and the stakeholders might take the screen layouts as working software.

3) Most logical thing would be to deliver a feasible amount of working screens in 1 sprint, so you can display the look and feel and get the technology for population them working. This reduces risks for user experience, screen population mechanics and stakeholder expectations.

> ...can a Sprint contain a mix of items
> 1) that can be released and
> 2) items that are in progress and are worth releasing in production
> only in the next sprint when they are fully functional ?

A valid Sprint Backlog could not contain such a mix of items. This implies that they cannot be brought into progress during the Sprint, so the answer is no.

A Sprint Backlog represents a Development Team's plan for delivering a potentially releasable increment of value by the end of the current Sprint. Work that is not intended for delivery by the end of the Sprint should not form part of the team's plan, and should not therefore be included on the Sprint Backlog. Work that is intended for delivery in a future timebox should be planned into the backlog for the relevant future Sprint.

If PBI's are too large to be completed within a Sprint, then they must be refined further and broken down into items that can be actioned within this timescale. Product Backlog refinement sessions may be used for this purpose.

I am not sure whether your suggestion will always work in a practical scenario. I'll tell you why I say that -
Scenario -
1) There are 4 developers in the team
2) 3 developers are working on an enhancement related to closing of a ticket in a customer service application. Sprint Goal - is to have this enhanced business logic for closing of a ticket to ensure no complaints are unintentionally closed
3) the next high priority items is a a completely new screen to be built. That screen has some 6 columns which need to be present. However, only 1 developer can work on this piece and this cannot be completed within one month

Question - In this scenario, can't we have the closing of a ticket enhancement pushed to production (shippable functionality) and the new screen (not shippable) available in pre-production environment?

> can't we have the closing of a ticket enhancement
> pushed to production (shippable functionality)
> and the new screen (not shippable) available in
> pre-production environment?

Not in Scrum, because that would mean planning for undone work at the end of the Sprint. Some work would be of production quality and some wouldn't. The Definition of Done would be compromised, and technical debt would accumulate for repayment in future sprints.

Work should only be planned from the Product Backlog into the Sprint Backlog if the team can include it in the potentially shippable increment at the end of the Sprint.

So, what ways can you think of to resolve the situation you describe?

According to Scrum, you do NOT have a potentially shippable, usable, working Increment.

I do understand that according to Scrum you should have a shippable product. However, in a practical scenario as I mentioned before, its difficult to have all your stories as a shippable product.

I still feel that you can have a mix in a Sprint for Production ready and Pre-Production ready stories. The key takeaway from Scrum for me is to have opportunities for inspection and adaptation so that any undesirable variances are caught early.

So with this, I still stand by my example of having the functionality of building a screen with as much functionality as possible and make it available in pre-production. With this the key stakeholders can test in the pre-prod environment to validate whether this would work in the real world.

I wouldn't be surprised to hear from folks that they have had items in the Sprint Backlog that didn't make sense to release in Production as they would be half baked products.

How do the PBI's (one that was released to production and the other available for end-user testing) rate against the "Definition of Done"? If the 2nd one hasn't yet passed Definition of Done criteria , then its not "Done".

Beginner Scrum teams usually have difficulty with getting selected PBI's completed into a potentially releaseable Increment -- this is why the Definition of Done is less stringent. As the organization's processes improve/mature (e.g. Continuous Testing, CIntegration, Continuous Deployment), the Definition of Done is made more stringent

No surprise -- that happens. In that situation, the items are marked "undone" and moved to the PBI to be completed in future sprints. Not sure whether the latest Scrum Guide talks about it, but one of the older-version Scrum Guides talks at length about "undone" PBIs.

Sprint Review - pg 12 of 2013 Scrum Guide
The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”
--------------------------------------------------------------------------------------------------------------------------------------------------
Done - pg 16 of 2013 Scrum Guide
When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this varies significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of “Done” for the Scrum Team and is used to assess when work is complete on the product Increment.

As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality. Any one product or system should have a definition of “Done” that is a standard for any work done on it.
--------------------------------------------------------------------------------------------------------------------------------------------------
Done Section - pg 10, version 1 of Scrum Guide

“Done” defines what the Team means when they commit to “doing” a Product Backlog item in a Sprint. Some products do not contain documentation, so the definition of “done” does not include documentation. A completely “done” increment includes all of the analysis, design, refactoring, programming, documentation and testing for the increment and all Product Backlog items in the increment. Testing includes unit, system, user and regression testing, as well as non-functional tests such as performance, stability, security and integration. “Done” includes any internationalization. Some Teams aren’t yet able to include everything required for implementation in their definition of done. This must be clear to the Product Owner. This remaining work will have to be completed before the product can be implemented and used.

TIP: “Undone” work is often accumulated in a Product Backlog item called “Undone Work” or “Implementation Work.” As this work accumulates, the Product Backlog burndown remains more accurate than if weren’t
accumulated.

TIP: Some organizations are incapable of building a complete increment within one Sprint. They may not yet have the automated testing infrastructure to complete all of the testing. In this case, two categories are created for each increment: the “done” work and the “undone” work. The “undone” work is the portion of each increment that will have to be completed at a later time. The Product Owner knows exactly what he or she is inspecting at the end of the Sprint because the increment meets the definition of “done” and the Product Owner understands the definition. “Undone” work is added to a Product Backlog item named “undone work” so it accumulates and correctly reflects on the Release Burndown graph. This technique creates transparency in progress toward a release. The inspect and adapt in the Sprint Review is as accurate as this transparency.

I think part of the issue is that Sujoy has twice mentioned "pushing" work to production. In an agile delivery model, work is not pushed, it is pulled. In other words there should be a tenable demand for increments of value that meet a Definition of Done of release quality.

When this pull isn't there, the DoD loses relevance due to a lack of stakeholder ownership. That's when work ends up being "pushed", and technical debt is allowed to accumulate until a release stage-gate is actually encountered.

Sounds like Scrumbuts.

In medium and large enterprises, the "undone" code that Sujoy is referencing resides in a user test environment. Referring to it as "pre-production" may lead one to believe that if the P.O (and biz users) are ok with the system, it can be migrated to production. However, it sounds like "pre-production" is really a user test environment -- it certainly is not a staging environment.