0

When creating iterations in Azure DevOps (Azure Boards), should non-development phases (non-sprint activities) be included in the dates for each sprint iteration?

My understanding is this: schedule sprint dates in Azure Boards around when development begins and ends (code freeze). This means that sprint planning happens ahead of a sprint iteration start date, and builds get shipped to QA after the sprint iteration end date/code freeze (assuming there is a QA testing phase after development). Planning, testing, deployment, and UAT occur outside of the dates specified in Azure DevOps sprint iterations.

Azure Boards really seems to be built around only 1 active sprint at a time. Developers need to be always working on the current sprint of development work. By limiting the iteration dates to only the development phase of Agile, there is no overlap in the development phases (sprints), and the Azure Boards tools work well with this.

The idea is to always keep work ahead of developers, in the sprints, and continue iterating.

But is that not ideal? Should the dates of the sprint iteration in Azure Boards include planning, testing, etc?

This is very difficult to lookup online, on learn.microsoft.com, on other sites, etc, and I was unable to find any information explaining WHICH dates are supposed to be used when creating sprint iterations in Azure DevOps.

Here's a visual of what I'm talking about:

  • Purple = planning phase (light is forecasting, dark is sprint planning just before sprint begins)
  • Yellow = development phase (actual sprint)
  • Blue = testing phase (QA)
  • Red = deployment
  • Green = UAT enter image description here

Attempt to reword the question:

Looking at my diagram, given the yellow boxes are development sprints, should those be the dates that are used for Azure DevOps sprint dates? Or should the sprint dates in Azure DevOps also include the time spent in sprint planning, QA, deploying, UAT, etc?

I may need to repost this as "What activities does Azure DevOps consider to be part of the iteration/sprint?" Is a two week QA regression on a release candidate considered part of the ADO sprint? Is deployment considered part of the ADO sprint? Is UAT considered part of ADO sprint?

Edit

Added clarification in a few spots, based on some feedback in answers/comments.

Improve this question
2
  • There are no "non-development phases." The central dysfunction is that you are failing to treat non-programming activities as part of the product development and emergent design processes. In Scrum, there is only one Sprint Goal; everything the team does is collectively focused on delivering that singular Sprint Goal to provide one or more Increments of the current, singular Product Goal. If you're doing anything else, feel free so but you can't officially call it Scrum. Commented Jul 31, 2023 at 3:10
  • @ToddA.Jacobs If QA receives a release candidate build and it takes them two weeks to validate it, does that two weeks count as "part of the sprint"? Are the QA team activities considered part of the sprint activities, or are they considered "external" to the sprint? Commented Mar 15, 2024 at 3:58

3 Answers 3

Reset to default
3

In Scrum, there's no such thing as "non-development phases" during a Sprint. Sprints have no phases. A Sprint begins with a timeboxed Sprint Planning event and concludes with the Sprint Retrospective. All activities happen concurrently within that timebox to move the team closer to a Sprint Goal.

If you have phases, a code freeze, and a handoff to QA for testing, you are not practicing Scrum as it's defined in the Scrum Guide. All these activities are intended to be captured within the Sprint.

Since I've never used Azure DevOps before, I can't say if it is possible to configure it in a way that supports your process. But I can say that your process isn't typical with how most teams implementing agile methods model their work. It seems like Azure DevOps is built around a more typical agile model. If you intend to use Azure DevOps in a Scrum-like configuration, your current process and the expectations of the tool aren't aligned.

Improve this answer
4
  • I am indeed primarily focused on Agile methodolgy, with scrum practices to achieve such. I've read on a few Agile docs that Iterations are the part where development occurs. See this article: activecollab.com/blog/project-management/…, it says "An iteration in agile is a time-box during which development takes place." Commented Feb 2, 2023 at 18:10
  • Also the Scaled Agile Framework describes the Iteration Execution phase as the "Do" part: scaledagileframework.com/iterations/…. It seems that Azure DevOps iterations are primarily focused around capturing the dates for the DO part, not the Plan, Review, and Adapt parts. Commented Feb 2, 2023 at 18:11
  • I'll also concede that testing in pure agile/scrum is performed inside the Iteration, without a separate testing phase. Thanks for your thoughts, but yes, I think this is fundamentally a question about Azure DevOps and what it expects for dates inside of it's tooling. Commented Feb 2, 2023 at 18:12
  • 1
    One of the challenges with Agile approaches is that SAFe borrows a lot of terms from other frameworks like Scrum and Kanban with varying levels of faithfulness. Scrum would not say that the that the iteration is part of the "DO" phase of the PDA cycle. It is very clear that the sprint encompasses all of it. Don't get me wrong, you can choose either, but SAFe definitely adds a lot of unnecessary confusion to people trying to learn these terms. Commented Feb 3, 2023 at 15:43
3

I'd like to share the direct answer, but then explain the why below. However, understand that I'm telling you what Scrum says you should do and why it is structured that way. Of course, if you don't want to practice Scrum, it's not for me to say it's wrong, but of course Scrum tools will be a poor fit. That said, let's jump into the answer:

Direct Answer:

There are no overlapping sprints in Scrum. Ideally, you will complete all backlog items by the end of the sprint timebox, but even if you don't, the sprint still ends. The scrum team then decides what to work on the next sprint. While it is true that the most beneficial decision is often to finish that work the next sprint, the team could decide not to (again, as per Scrum) and should always be striving to minimize this occurrence.

The Why:

Scrum was designed to enable adaptability in product development. Waterfall is far more optimized toward efficiently doing a known set of work. The reason scrum became popular was because people kept doing "known" projects and either never getting to the end due to unexpected changes or they'd get to the end to find they'd built the thing the plan said to, but it didn't meet the end users' needs. This is really important because the reason for no overlapping sprints is all about adaptability. If you don't need adaptability, you don't need scrum (but I question anyone who says they don't need adaptability because I've seen so many projects that say they don't, then fail because they really did).

How does Scrum enable Adaptability?

In Scrum we start the sprint by setting a goal that moves the product forward. For example, "At the end of the sprint, users will be able to do X". The rest of sprint planning is identifying the work to reach that goal. We then do the work and ideally reach that capability in the timebox of the sprint. Then we show it to stakeholders and customers at the review and ask ourselves and them "now that the product does this, what is the next thing it should do?". These clean lines between sprints mean that even if we thought the next sprint would focus on feature Y, we could decide to switch to feature Z in order to meet an emergent need. If work is always part-done, this type of adaptability becomes impossible.

Improve this answer
1
  • If QA receives a release candidate build and it takes them two weeks to validate it, does that two weeks count as "part of the sprint"? Are the QA team activities considered part of the sprint activities, or are they considered "external" to the sprint? Commented Mar 15, 2024 at 3:57
2

The point of iterations is that they are timebound rather than being defined by scope or phasing; overlapping sprints for the same product/outcome therefore doesn't make much sense. Problems arise because you seem to be trying to fit very contrary concepts (phases and code-freezes) into an agile way of working.

Think of sprints as contiguous blocks of time, and then allow the team to fit work into them based on defined priorities. I also wonder about your team size and sprint duration. Keep teams to no more than about 10 people and sprints no more than about 10 working days. Your diagram, if accurate, suggests that planning takes longer than development which seems pretty extraordinary!

Improve this answer
1
  • Thanks for your thoughts. I should have expanded on the diagram, as that might be confusing others as well. Light purple is "forecasting" where Product Owner is pre-assigning work to sprints, then dark purple is actual sprint planning as the sprint team, where the sprint plan is firmly established. That sprint planning occurs just before the sprint starts. Commented Mar 15, 2024 at 4:00

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.