1

We're struggling to break Product Backlog Items (PBIs)/User Stories into Sprint-sized chunks as we have multiple steps that need to be completed in a linear fashion.

Each release goes through several steps:

  1. Development (Dev Environment)
  2. Testing (Test Environment)
  3. Staging Testing (Staging/Pre-Prod Environment)
  4. User acceptance testing (UAT) (Staging/Pre-Prod Environment)
  5. Deployment to Production

We can generally get the development and testing finished in a Sprint and the UAT gets completed the following Sprint. It makes sense to have the UAT tasks under the same PBIs that are used for Development and Testing to prevent duplicating the PBI/User Story. The problem is having PBIs always open for more than one Sprint means that our Sprint backlog becomes too big, hard to manage and difficult to get metrics from. It also sets a precedent where we start saying Testing can be in a different Sprint to development, etc.

As I understand it we have the following options:

  1. Continue as we are.
  2. Create a separate, duplicate PBI for UAT tasks. The PBI would be copied from the main PBI.
  3. Create a general UAT PBI that includes all tasks required for UAT for that release.

Due to other processes which we can't change UAT cannot be in the same Sprint as development and testing.

We currently use Visual Studio Team Services/Azure Dev Ops.

Would would be the best practice for this?
Are there any other options that I've missed?

1

TL;DR

Your UAT process is currently external to your development team, and your delivery and deployment are tightly coupled. Without changing your underlying process or business assumptions, there is no way to make what you’re currently doing “agile.”

However, you can:

  1. select a more approrpiate agile framework,
  2. improve your agile practices,
  3. redesign your development and delivery processes, or
  4. accept the costs of doing business with your current implementation as-is.

While different answers may provide you with various potential solutions, they will typically fall within one of these four buckets. Which of the available options you choose will largely be a business or political decision, so be sure to factor that into your decsion-making process.

Analysis

Thanks but when we push to the staging environment for UAT we need to push the whole release in one go. This allows us to treat it like a dry run testing our production deployment. This means that the UAT can't be the same sprint as Development, no matter how long we make the sprint.

Despite the original question, the real problems, as described in comments, are:

  1. UAT is an external process.

    The UAT team and process are not internal to the development team, and therefore outside the span of control.

  2. Delivery and release of each increment are tightly coupled.

    By equating delivery with release, especially with an external dependency, your process can’t meet the Definition of Done within a single iteration.

Once you acknowledge these two built-in process problems, you can begin evaluating solutions.

Potential Solutions

There are a large potential pool of possible solutions to your problems. Which ones are politically palatable, and which ones make business sense to your organization, are going to vary greatly from company to company.

In no particular order, some of your options include:

  • Do Lean or Kanban, not Scrum.

    Even though the question wasn’t tagged Scrum, the notion of “Sprints” is generally a sign that a team is trying to follow Scrum. However, if you are routinely unable to meet your Sprint Goals within a single iteration for institutionalized reasons that will not change, then Scrum may not be the right framework for you.

  • Internalize UAT.

    If UAT is outside the team, it is possible to bring it into the team. Whether or not that’s something your company wants to do is a completely separate issue. It’s possible, so don’t dismiss the notion simply because it’s not the way the process is set up today.

    A Scrum Master or agile coach should actively educate senior leadership on fundamental process problems like this. Allow the executive team to earn their paycheck by solving organizational process problems.

  • Decouple delivery from deployment.

    In an agile framework, each cycle or iteration should deliver a potentially shippable increment of work. However, you don’t actually have to deploy it just because it was delivered.

    Many agile teams use feature toggles and other continuous delivery practices to enable the team to deliver features at Sprint boundaries (or even more often), without necessarily having to deploy those changes to non-development environments. By removing deployment to your UAT environment from your Definition of Done and leaving it up to them to enable feature toggles when they’re ready, you create the ability to decouple those elements of your process.

    Of course, this means any issues discovered in UAT will need to be sent back to the Product Backlog or input queue as new work to be estimated, prioritized, and scheduled in accordance with your agile framework. You have lots of flexibility in how you do this, but the one non-negotiable is that you cannot have an external process that hijacks or bypasses your internal agile process.

    By choosing to have separate teams or an external testing process, management must accept the trade-off that UAT and deployment are out-of-band, and that the external processes can only create new work for the team at iteration boundaries and through the consumption of team resources that must be pulled from other activities. One way or another, this is true regardless of the agile (or even non-agile) framework you’re using!

There are other solutions possible, too. However, what they all have in common is that you (the collective and organizational “you”) must re-evaluate your current assumptions, and then inspect-and-adapt until you have achieved a more efficient process. Note that accepting the drag on productivity and financial costs of continuing to do business the way you do today is also a legitimate business decision, but that management can’t have both “business as usual” and “continuous improvement” at the same time. TAANSTAFL.

  • Todd, great insights here. I believe we're on the same page when it comes to Kanban, but I believe Kanban and Scrum can play nicely as indicated by Scrum.org's Kanban for Scrum guide. Unless Kanban's pull system indicates otherwise, there's merit in decoupling UAT from a "potentially-releasable" increment by delineating the two in a strong Definition of Done. I'm of the mind to inspect your sprints using Kanban practices, THEN decouple in the event it's deemed necessary. Again, it sounds like we may be on the same page there. – dom_michalec Oct 29 '18 at 16:14
  • Excellent answer thanks. Took a few days to mull it over and I'm going to propose that we move the sprint to four weeks with UAT starting half way through the fourth week. This means the Dev's would be finished, which was the problem about UAT being in the same sprint, but the Devs can then do solutioning for upcoming features, breaking PBIs down into tasks etc. Something we've needed more dedicated time on for a while now. – Jay1b Nov 2 '18 at 7:47
1

Great question. It sounds like your backlog has a bottleneck at the UAT state of development. Scrum.org has addressed the bottleneck issue by infusing Kanban practices into Scrum to provide hyper-transparency into scenarios like the one you've described.

Having an ever-growing Sprint Backlog is an artifact of this kind of bottleneck, resulting in a sprint backlog that is hard to manage because the list of work items continues to grow. This is addressed by Little's Law. In essence, the fundamental result of Little’s Law is that for a given process, in general, the more things that you work on at any given time (on average) the longer it is going to take for each of those things to finish (on average).

Limiting Work In Progress (WIP) and having your team understand its own definition of workflow can unearth the reasons behind this bottleneck without the need to duplicate efforts from sprint-to-sprint. It sounds odd, but slowing down the workflow by limiting WIP is effective in understanding why items stall in certain states (in your case, UAT), giving you the opportunity to address those issues while also providing a mechanism to efficiently complete work. Blockers and inefficiencies become qualifiable when using these techniques, thus making them easier to address.

All of this can be found in the 2018 Kanban Guide for Scrum Teams. Hope this helps!

  • Thanks, a really good insightful answer. I think the problem lies with that we literally can't have UAT in the same sprint due to some other processes, I don't think I made that clear in the my original post. I was thinking last night that we need to change our processes to enable this. – Jay1b Oct 30 '18 at 7:52
-1

You have one (or both) of the following two problems:

  1. Your stories are too big. Split them further! Try to follow the INVEST method.
  2. Your Sprints are too short. Make them longer.

Personally, I would prefer the first solution. But, if you've already split your stories as much as you can, then it would be preferable to have longer Sprints than to always be carrying everything over two Sprints.

when we push to the staging environment for UAT we need to push the whole release in one go. [...] This means that the UAT can't be the same sprint as Development, no matter how long we make the sprint.

One approach I read recently was to have two separate Definitions of Done (DoD). The first (up to but not including UAT) would cause the story to burn down, but on the Sprint board it would remain in a 'waiting for UAT' column. The second DoD would be for when it's deployed.

  • 1
    Thanks but when we push to the staging environment for UAT we need to push the whole release in one go. This allows us to treat it like a dry run testing our production deployment. This means that the UAT can't be the same sprint as Development, no matter how long we make the sprint. – Jay1b Oct 29 '18 at 14:08
  • 1
    @Jay1b You’re describing an anti-pattern. Your single-iteration Definition of Done should include in-Sprint UAT and deployment to higher environments, or the Definition of Done should stop at delivery to UAT. You can have a two-stage process or a unified process—you can do either; you just can’t have it both ways. – Todd A. Jacobs Oct 30 '18 at 5:05
  • Reason for downvote? If someones disagrees, I'd like to know on what/why. – Sarov Nov 2 '18 at 13:22

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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