If you’re following this blog series, you should have already selected your process template and decided whether to use area paths. Now that those things are out of the way, you’re ready to start setting up your sprints.
Set Up Your Sprints
The process for doing this in Azure DevOps is a bit wonky, and I find that I almost need to re-learn how to do it each time I start a new project. (By the way, to manage sprints / iterations, you must have permissions as a site admin; otherwise, you will get an error indicating that you don’t have proper permissions.)
First, go to your Settings icon (it looks like a gear wheel). From there, go to Boards > Project Configuration. There you will see the root name of the project. Make sure you are on the root (or the correct area path), and then click New Child (or you can right-mouse click and select the option from there, too).
You will need to manually decide what to call your sprints or iterations. My advice is to pick a convention and stick to it consistently to avoid confusion. Some teams I have been on included the sprint dates along with a sprint number; others just use the sprint or iteration number (starting with Sprint 1). Some teams include the project name in their sprint titles because their entire organization is using Azure DevOps, and this helps with enterprise-level reporting. Make sure you understand and follow any organizational conventions.
After entering a name for the sprint, select your sprint start and end dates. Azure DevOps then knows the length of each iteration – which are prepopulated starting the day after the last sprint ended. Otherwise, you can manually select a start and end date using the calendar picker (or simply type in the dates).
Create as many sprints as you have planned for your project / product. You can always add more later, but I find it’s simpler to do it all upfront so you don’t have to worry about it each sprint.
Once you have your sprints set up, you must then choose which sprints to show the team. I know, this is odd (at least to me), but it keeps the views clean, and it doesn’t show sprints too far into the future (if you don’t want to). To do this, go to Project Settings > Team Configuration, and go to the Iterations tab. Use Select Iteration(s) (or Sprints), to add the sprints that you want to display on the board.
You can also use this to remove sprints you no longer want the team to see. If you don’t want them going to past sprints, you can control that here, too. (Please note: if you remove a sprint from this view, it doesn’t remove anything in the system – it just hides that link from the team.)
Regardless of whether you are using Scrum or some other flavor of agile, the principle behind agile is to deliver value (a.k.a. working software or product) at the end of each iteration – including the very first one.
Many organizations believe they need a setup period to prepare the development team to deliver anything of working value. While there may be very logical and compelling reasons for this, I see this as a wasted iteration in which the business will not realize any tangible value. I prefer to start sprinting immediately.
If there is setup that must happen, get it done as quickly as possible and don’t use this as a buffer period before getting into development. However, I also recognize this is not always realistic – depending on the steps to get set up, the size of team, the complexity of the technology, etc. If a setup period is needed, whatever has been set up should still be demonstrated to the business so they understand the investment that was made to get the team prepared to hit the ground running.
Now that you have your sprints all set up, you’re ready to add your team so you can start sprinting!