My team has been using Scrum for years with a goal to deliver a potentially releasable build each sprint. We recently started using a Kanban board moving away from time-boxed delivery to feature-boxed delivery. So far, this seems to better fit the teams natural way of working. With feature-boxed delivery, stories are pulled from the backlog when an individual feels they are comfortably ready to begin working on it.

The teams average story lead time is three weeks. So, theoretically, at the moment the product owner asks for a release, the team should be able to deliver it three weeks later.

When the PO sets the "stop development" trigger, individuals who have time are supposed to start helping with stories already underway to begin clearing out the board. The people freed up first are typically the "front-end" folks... Those more skilled at analysis and development. They are typically asked to help with back-end work, like system testing.

The teams work flow, or cadence changes each time the stop trigger is set. What do you do to minimize this change and keep the team working as efficiently as possible? How do you avoid the disruption caused by the Product Owner asking for a release?

  • "The teams work flow, or cadence changes each time the stop trigger is set" Why? what kind of change exactly?
    – xsace
    Commented Oct 23, 2011 at 8:48
  • @xsAce, good question. In Kanban, an individual will pull a story from the backlog when they finish the current work. This means that the product is adding new user value continuously until the story queue is empty (the stop trigger). Thus flow changes. John's answer was good but branching has it's own set of problems so I was hoping to see one or two more answers. From John's thoughtful remarks, I am seriously considering branching as a solution.
    – GuyR
    Commented Oct 24, 2011 at 13:42

1 Answer 1


The way you describe it preparing for a release is a significant interruption of your workflow which appears to work otherwise.

As we had a similar demand placed on our team we introduced the following solution. It has mainly to do with branch management in your version control system. The concept is known to me as "No Junk In The Trunk". It basically means that you have a branch that is 'clean' in that it contains only work that has successfully passed Quality Assurance (QA). Using Subversion this branch may be called 'trunk' hence the name. Of course this works with other version control systems as well, e.g. GIT.

When we start work on a new feature then we create a feature branch. This feature branch is updated with a merge from trunk at least once a day to keep the difference to a minimum. All testing, quality assurance, sign-off by various parties is entirely done on the feature branch. Once the feature is complete it is then merged back into 'trunk' followed by a quick integration testing focusing on where the new feature integrates with what is already there.

When we release we create release branches out of 'trunk'. Since 'trunk' is 'clean' we can pretty much release at any time. Since releases do not depend on wiping out all stories from the Kanban board we can prepare a release at any time without interrupting the regular development workflow.

This process works very well for us. Creating the release branch takes about 10 seconds as it is fully automated. The most significant item on the release branch is reviewing the release notes by a native English speaker. This is unfortunately a manual process and it takes about one or two hours depending on the amount of new features and bug fixes in the new release.

As always you may have factors in your environment that may make other solutions to the challenge a better option.

  • 1
    This is an excellent approach, and earned a +1 from me. Commented Nov 24, 2011 at 3:11

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.