2

My question is simple. We are hesitating whether we shall include Product Release as a task in our sprint board.

2
  • In a Sprint process, tasks will or will not be accepted by the product owner during the Sprint Review. Any release must be outside this process. For me the Sprint and the Release must belong to different units
    – AED
    Commented Jul 21, 2017 at 9:00
  • @AtmaneElBouachri can you please support what you with a reference? It sounds interesting.
    – Amio.io
    Commented Jul 21, 2017 at 12:22

2 Answers 2

2

The challenge to move teams into Scrum or any other Agile process method is finding the balance between what needs to be tasked out and what should be inherent in the process.

One of the vital aspects to the Agile process is that the structure is fluid and not every part of the process framework needs to be followed to a T.

What I have found works is to gather the team together, outside of a standard planning or team session, if a separate meeting is not feasible then use the teams retrospective, and decide as a team what would be best for now to either have the Product Release as a task or as a general mental checklist item. The plus side of having it as a task is that it works the deliverable into the process and into the minds of the team. Once the team has refined its process then the task itself as a ticket can be eliminated.

4

TL;DR

If releasability isn't part of your Definition of Done, preparing a release needs to be treated like any other actionable set of backlog items. Except in the most trivial cases, you should strive to decompose your release tasks into done/not-done items for your Sprint Backlog.

Bake Releasability Into Each Sprint

In Scrum, your team should have a potentially-releasable product at the end of each Sprint. Your Definition of Done for each Product Backlog Item should therefore already include all the tasks needed for the work to be releasable.

This is foundational to Scrum. There are certainly real world cases where there's still irreducible daylight between "potentially-releasable" and actually shipping the product, but the goal of the framework is to minimize the distinction whenever possible. When not possible, then you have an obligation to surface all the effort required to ship the release and make it explicit during Sprint Planning and on your Sprint Backlog.


"No invisible work, ever!" —CodeGnome's Law of Transparency


Make Release Work Visible

If there's additional work that needs to be done to release the product, then that work should be in a story (or set of stories) on the Product Backlog, and associated stories and tasks placed onto the Sprint Backlog during Sprint Planning. "Product Release" is not a story—it's shorthand for a bunch of things that may or may not vary between releases—and doesn't meet INVEST criteria as written. Except in the most trivial cases, you should strive to decompose your release tasks into done/not-done items for your Sprint Backlog.

Release work is like a pre-flight checklist. How long is the checklist? What items are on it? What's the level of effort required to tick all the boxes? Does the checklist vary between releases? You have to answer this question anew for each release Sprint to ensure you allocate sufficient team capacity and that the work indeed fits completely within the current Sprint.

If you don't do this, the work is largely invisible. Invisible work can lead to problems with forecasting or meeting the Sprint Goal because the work isn't properly accounted for during Sprint Planning. All work done by the team consumes capacity whether you track it or not, so release work must be visible and transparent to the entire team rather than wrapped up into a black box labelled "Product Release."

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.