0

When creating iterations in Azure DevOps (Azure Boards), should non-development phases 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 between the previous and next 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
  • Yellow = development phase
  • Blue = testing phase enter image description here
Improve this question
1
  • 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.
    – Todd A. Jacobs ♦
    Jul 31 at 3:10

3 Answers 3

Reset to default
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
2

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."
    – ryancdotnet
    Feb 2 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.
    – ryancdotnet
    Feb 2 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.
    – ryancdotnet
    Feb 2 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.
    – Daniel
    Feb 3 at 15:43
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

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.