5

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.

Improve this question
3
  • In agile/scrum, versions (especially those released to production) and sprints have very little to no relation to each other. The strongest relation is if you don't practice continuous delivery, in which case a version spans an integral number of sprints (1 or more, but no partial sprint).
    – Bart van Ingen Schenau
    Jun 14, 2017 at 10:35
  • 1
    You're saying it does not matter if stories are closed at the end of a sprint as far as the version is concerned? My understanding is that a version is a deliverable and that a story should be closed and removed from the board once it is Done. If the definition of Done is that it is released to live, this is a problem for us as that could be a long time. I'm trying to avoid that as a concern for the developers.
    – Matt W
    Jun 14, 2017 at 10:41
  • 1
    If your DoD requires stories to be released to live, then either you should release to live multiple times in a sprint (continuous delivery) or you should amend the DoD.
    – Bart van Ingen Schenau
    Jun 14, 2017 at 10:47

2 Answers 2

Reset to default
7

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.

Improve this answer
7
  • 1
    I would recommend that the board used by the team doesn't show Done items from previous sprints (even if they are still visible and open on other boards for the release team).
    – Bart van Ingen Schenau
    Jun 14, 2017 at 10:50
  • @Bart It depends on your perspective. For an individual team I use filters to hide those things during stand-up and review/retro. It depends on the capability and configuration of your tools.
    – Thomas Owens ♦
    Jun 14, 2017 at 11:07
  • I guess the question becomes "does the tool we're using (which happens to be Service Now) support dropping off stories and collecting the points when they leave one board (Dev) but not another (Release)?" I think this is possible.
    – Matt W
    Jun 14, 2017 at 11:45
  • This is a good answer, but I would question calling something done until it's in a user's hands. OP would do well to calculate the opportunity cost of letting stories sitting around unreleased. Inventory is waste after all.
    – RubberDuck
    Jun 14, 2017 at 14:03
  • @RubberDuck Yes, inventory is waste. But there are good reasons to not release after every iteration, for example the impact of testing in a system that needs qualification. It may be easier and less costly to batch. In such a case, perhaps deploying to a non-production system can get feedback. But methods to obtain feedback from users faster is a separate problem that exists regardless of why the decision was made to have a release cadence different than the iteration cadence.
    – Thomas Owens ♦
    Jun 14, 2017 at 14:05
0

"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.

Improve this answer
1
  • 1
    > 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. < I wouldn't call it a mistake. In fact, I would say it's far better to be in a place where people recognize that "done" software is useless and not really done until real users are actually using it.
    – RubberDuck
    Jun 15, 2017 at 21:42

Your Answer

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

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