When agile versions span multiple sprints

Question

We're using Service Now and have 2 week sprints. Our management team want to release to production once every 6 sprints and use the term Version for this.

When a story is complete in terms of development and testing, prior to production release, it will sit in the Done column (far right of our board.)

If a story is not to be deployed to production until the release team is ready, how should we move the story out of the sprint without losing it completely? The story is Complete but not truly Done. It may be some weeks before the story is released to production.

What is the recommended way of handling this 'version' scenario and does Service Now provide it?

---

My take is that:

a) Stories would be moved to Done and leave the board at the end of a sprint. The release build is put together on a given branch and any post-release issues are dealt with via either rollback or a new story in the backlog. (Currently the team making these decisions want stories which are not released to production to stay in the last column of the board.)

b) I can't see how Service now provides the agile concept of a Version.

Answer 1

At the end of an iteration, it's not required to release a software product. Scrum calls this an Increment, and other methodologies may have different names. The purpose is the same - at the end of your iteration, have something that is in a state that could be delivered to a customer or user.

I can't speak to the specifics of Service Now (and this community does not provide support for specific products or tools), but what you want should be achievable. I currently use Jira, so I can describe our flow there.

Backlog items start in Open. When a developer cuts a branch (for a code change) or starts working on an item (for something that isn't code), the ticket is moved to In Progress. When the work is being reviewed, it goes to Under Review. Once the development team says it's done, it goes to QA Review (I work in a regulated industry, so we need independent test of all work) and then Ready for Release. It stays there until the release is done, at which point things are moved to Released and then fall off the board. Any item that is in the "Ready for Release" is considered done and counts toward our burn down.

I would recommend consulting the support channels for your tool. My recommendation would be to have a "Done" column that indicates that your work is done, however you define it, and is ready to release. Then, be able to put the item into a "Released" state, at which point it falls off the board. Ideally, things that are Done would count toward items completed in your sprint, but you'd also want them to stay on the board until they are actually released and the release team can move them to the Released state. Filters can show/hide these from the development team, if necessary.

If the tool that you have doesn't support your process, then you have decisions to make. In my opinion, tools (especially expensive ones) should conform to the way that you work. However, you may not be able to simply change the tool and you don't want to fight the tool - it'll only make doing your job harder. So you need to evaluate the workflows that the tool gives you and see if there's something comparable. Perhaps small changes to your process, maybe in conjunction with configuration changes to the tools, can bring you to something that works well.

Answer 2

"Done" doesn't necessarily mean "deployed". The point of Scrum is to have an increment of potentially releasable, done, working software. Your release schedule really has nothing to do with your sprint schedule. There's many organizations that still maintain a quarterly or yearly release, while actually building their software in a series of two week sprints. Any backlog items that are "Done" do not carry over into your next sprint, whether they are release or not.

Ultimately, this boils down to your Definition of Done. If your Definition of Done includes "Deployed to production", that's probably a mistake, as that really shouldn't be a qualifier of whether something is "done" or not. Even if your release schedule corresponded with your sprint schedule, you still wouldn't be able to mark anything as "done" until the end of the sprint, which would seriously screw with your burndown.

Long and short, just divorce the two concepts entirely. Your PBI is done when it's merely in a releasable state. When or if it ever gets released doesn't matter.