Deployment in Sprint (Scrum)

[Russell Brown]

Good Morning...

We are struggling with our workflow as a team, and I believe other teams have to deal with the same issues...

So we have three 'To Do' Status (New, Ready, Assigned) and then we have three 'Doing' Statuses (In Dev, QA, Accepted), then two 'Done' Statuses (Deployed and No Longer Needed)... we also have Blocked Status that is used almost everywhere.

The problem is our team does both Production Support and Large Projects... Smaller stories are easy, but larger projects require work to sit in a UAT environment for multiple sprints until the business signs off.

Currently, our Sprint is technically Monday through the following Friday (two weeks), and then our Deployment team works off that board to Deploy to Prod the following Wednesday.

So technically, the sprint stays open until the work is deployed, but the deployment is after our set sprint... So we're struggling with our Burn-Down Chart and other metrics, and our deployment team is confused about what stories go where... 

For teams doing scrum... how do you manage your deployments, how do you handle for UAT, and when do you consider your stories done?

[Karin van Driel]

Hi @Russell Brown ,

It sounds like there needs to be a separation between Release deployment and Development, with a Definition of Done for your stories that is separate to your deployment and UAT schedule. The way we manage this is by using releases (aka Fix Versions) and Epics (aka Features).

We create Epics (we call them Features) for each piece of functionality we want to deploy. The Epic is broken down in one or more stories, which are small enough that an Agile Team can complete Dev and QA for that story in one sprint. The stories are sized and planned into sprints. We then assign a Fix Version to the Epic and to the stories.

Once the Agile team has completed their Dev and QA, the Story is marked as Done. The related Epic is set to 'In Progress' as soon as a team starts working on the first story (can be manual, or if you have Automation available to you, you could trigger the status changes of the Epic from the status changes of the stories in it). It stays 'In Progress' until all the stories are complete, at which stage it is marked as 'Ready for UAT' (you might want a separate status to indicate 'Ready for UAT Deployment' first).

The Business teams then start testing in UAT at the Epic level and once they have completed testing, the Epic is marked as 'Ready for Production Deployment'.  If they find issues during UAT, they raise bugs for the team under the Epic, which are sized and planned into sprints. If the Release (fixVersion) needs to be adjusted, for instance if the date cannot be met due to showstoppers and the time they take to fix, we do that. Once the release has been deployed to production and everything is working, the Epic is marked as Done.

We have a Scrum board for the Dev/QA team, which just shows the stories ready for them to work until Done. 

We have a Kanban board for the business, which just shows the Epics and their statuses.

We can check the state of a release, by viewing it in the Release menu; it shows all the stories in the release and where they are completion wise. 

This helps us by separating the Team's Dev/test work from the Acceptance testing and the deployments. 

Teams may also have Deployment tasks in their board, which are also sized, so that all work can be planned, the team knows what they need to do within a sprint and we don't over-commit. 

Another tool you may find helpful for all this planning and execution is the Roadmap tool; not sure what version of Jira you are on, but if you are in Cloud then it should be available. It allows you to see the work on a timeline, which can be very helpful for planning. For this to work, your Epics and Stories need to be in the same Jira project. 

That's a quick, high level overview, happy to go into more detail if it's helpful :)

[Ole Treptow]

God Morning Russel,

I strongly recommend @Alexis Evans suggestion and @Eric Rickert idea, though I would make a difference between failed UAT and CRs. CRs have to be paid.

But I'd like to emphazise the question: How is the team working with the Board? Do they follow a pull or push approach when it comes to assign the work? If nobody's working on the story, why should it be assigned? This thought might help you to get rid of unneccessary columns. If you're sure you need all the columns (I am never sure about that), reconfigure your workflow. At least you'll get some metrics right.

Needless to say, involve the team, let them design, provide guidance.

[Ron Skyberg]

In my opinion, DONE means:
Work has been completed by development + Work has no open bugs + Work has been accepted per the original elaborated stories by the business unit/requestor + Work has been successfully deployed to a production environment (and hopefully any bugs are from stupid user tricks doing really bizarro edge cases...). 
Done is done. Done is what we strive towards. 

Now, having said that, it is very common for working units to have different definitions of DONE : Engineering might consider checking in code to a repository as Done even before it goes through QA or UAT; business might not consider it DONE until they see the work in production; QA might not consider a story 'Done' until all related bugs are closed. Epics and Stories can also be 'un-sprinted'; and the Tasks/Subtasks can be pulled in to sprints. Once all tasks are Done, the epic/story for those tasks is Done. 

So, my first suggestion would be to get everyone to agree on your team's specific definition of 'Done'. Does it mean Accepted or Deployed to production -- not by a status, but by what the business connotation of Done is for your organization. 

Your team might consider DONE as waiting for deployment. 
Devops might consider DONE as being deployed without issue. 
Corner Offices might consider DONE as being deployed and paid for by a customer (depending on your type of work of course).

Once Done is agreed on, you can begin to reconfigure your workflows to compensate for states of 'done-ness' and begin to adjust sprint timeboxes and boards as needed; such as @Alexis Evans  / @Ivan Ferreira  recommendations for separate boards. 

The metrics will follow after 3-4 sprints of working in the new schemes, allowing you to provide metrics based on your definition(s) of Done-ness.

[Eric Rickert]

Hi Russell,

Our scrum team uses Jira releases/fix versions to store done work that is waiting on deployment. I'm able to create multiple fix versions or release branches to mirror our development branches and group completed work together as needed. Done work assigned to a release branch can then be provided to the Client for UAT, any change requests are created as a new jira(s), pulled into the sprint to be completed, and assigned to the release fix version branch they will affect. This helps us to keep track of completed work awaiting client/stakeholder approval for deployment, close our sprints on time, and keep our boards clean. 

https://www.atlassian.com/agile/tutorials/versions

[Alexis Evans]

My current team doesn't do quite the same kind of work, but I do have an idea. Could you set up a separate board for your deployment team? Maybe you can replace your Deployed status with simply Done, and then have a different workflow for issues in your deployment board. Then, each time one of your development stories is transitioned to Done, you set up a Jira automation to create a new task on your deployment board to deploy that work. Then, your deployment team would work off of those and mark them as Deployed once they're deployed, and meanwhile, your development team can mark your stories as Done during the sprint.

I'm a relatively new scrum master so there could be something specific about your workflow and stuff that I'm missing, but I wanted to put my idea out there in case it's helpful to you. I also know that Jira automations are built into Jira Cloud, and relatively recently became built into new versions of Jira Server as well (along with a free add-on for older versions), so you should have access to that feature. It's pretty easy to use.

[Michelle Yip]

- Look out for the scope mentioned in the ticket, and make sure to avoid scope creep during implementation. You can always raise a separate ticket for future iterations.

- Get the QA team involved right from the start of discussions or workflow walkthrough!

- Use the Release Version changelog to help you get ready for deployments - there're a few templates in Confluence. 

[Ivan Ferreira]

Hello Russel, every organization and every team has different working schemes. I think in a few options for your case.

Option 1

If I understood correctly, there is about one week between development done, UAT, and deployment.

The easiest solution here is to change the Sprint duration.

You should also consider that you velocity should not be the velocity of just one sprint, but the average velocity of several sprints. So, in this case, if one user history is moved to the next sprint, in about 3 or 4 sprints you will get your real average velocity.

Option 2

Change your definition of done. In this case, you will consider done just before the UAT and deploy stages. You could send or clone the Issues to another board, as Alexis suggested. This will give you better metrics in your burndown chart.

You can even have one board displaying the tickets of multiple projects (Development Project, UAT Project, Deployment Project), but I’m not very fan of this approach, as the value stream start to have “Silos” metrics. Another issue to consider is when UAT rejected your finished story. Eric said that any change request is pulled as a new issue.

Option 3

Use EPICS and versions, as Eric suggested. You can then report by version or EPIC instead of by sprint.