So, quick reminder: this series of posts covers how to use the basic features of Azure Boards, a subset of Microsoft’s Azure DevOps product, to help organise your tasks and projects, even if you’re not a developer or project manager … and even if you’re a small business owner, IT Pro, freelancer or someone who wants to organise their work to get things done. You can read the introduction here and review how we itemise and organise our work, no matter how small it is, over on this page.

In this blogpost, we’re going to review how you organise what you’re doing by time… which suggests time management. Now, before we delve into specifics, I’ll be blunt: time management is not my forte and I’ll be the last to call myself a time management expert. That said, I’ve tried a few different methods in my search for better ways to extract more things-done from my todo list so I’d like to think that I’m talking from a place of experience. So, probably the best way of thinking about time management in Azure Boards is not blocking out time in your calendar to do things, making commitments to yourself or any of those more tactical measures, but by time boxing.  Now it’s not as violent as it sounds, but in effect it’s blocking out a period of time to get a specific thing or things done but over a span measured in weeks rather than hours. 

To keep things somewhat easier, each block of time is a set size (common sizes include one week or one fortnight) so that a given time period (like a year) is broken down into a set of regular intervals of time.  These intervals are referred to in Agile-parlance as sprints (you might also hear the term iterations in Azure Boards).  

You might be thinking, why bother with this for what I’m doing? Well, if you consider that a lot of your work might be project-oriented, with start and end dates and tasks that might need to be broken down into smaller tasks, you can see pretty quickly how trying to fit that into calendar appointments and tasks in Outlook or the like might become a bit unwieldy quite quickly. But if it’s a sufficiently small project, you might not want to spend lots of money on a dedicated piece of project management software to help you get the job done.  

What might help is an example, and based on the last post let’s continue with the music festival scenario. Let’s say we’re going to Glastonbury, which starts on June 24th and it’s April 26th today.  We’ll setup a weekly sprint length, which gives us approximately eight full sprints and an additional one that covers the start of the festival as well.  We’ll start each sprint on Monday, so that sprint 1 goes from April 27th and finishes on May 3rd, with the next sprint starting on Monday May 4th.  

So this is all fine that we’ve broken down our calendar into weekly blocks, but now what? This is where we pull in our backlog.  You may remember me mentioning the term backlog from our last post on work items. The backlog is effectively the list of new and uncompleted items you have in your project (although you can see completed items in your backlog as well). So using our festival example, if you haven’t bought a tent yet, then the piece of work that covers that would be classified as on the backlog. In Azure Boards, you can view the backlog from the perspective of Epics or Issues (or if you were using the Agile method, Epics, Features and User Stories but that’s another post for the future) and the work items that are children of them. You can access the backlog from the left hand menu.

From here we can see all of the items that we’re working on, organised by the work item hierarchy, giving us a clear picture of all of the outstanding work. We can then assign work items to sprints to help us figure out when to do things.  For example, I might want to get my tent sorted out early to ensure I have time to do other things, so I can assign that work item to one of the first sprints, but I might buy food for the journey right before I go, so I’d add that to a later sprint closer to departure time. I can also re-order my items by dragging and dropping them to different positions on the backlog; typically, you move the most important items to the top and least important items to the bottom, so that you and your team can see which items are more important to complete. For example, the Transport Issue is the most important (because none of the other items matter if you can’t get there), with the Accommodation Issue being next, Gear following afterwards and Food being least important (I can always buy food at the festival).

So to complement this, there’s also the Sprints view. The Sprints view shows the work items as well, but using the perspective of a specific sprint instead. This way, I can get a visual depiction of the work we’re aiming to finish during this sprint, what the overall project workload for the sprint is, and what’s coming up on future sprints (or past sprints, for items that have already been completed or need to be pushed forward).  In the picture below, you can see that I’m looking at Sprint 1, that I’ve got two issues and three tasks to complete this sprint (aside from counting them in the list in the foreground, there’s also a count under the specific sprint in the Planning column), 

So, to make things clearer, here are the side-by-side pictures of the sprints and backlogs views:

On the left, we have what we would see in the Sprints view.  Only a suibset of the full task list is shown, but it allows us to focus on what we’ve determined to be the work required for this time period.  On the right, we have the Backlogs view, showing us all of the tasks we’re working on to give us a strategic view of what’s happening in our project, but not necessarily when.

So, to underline the value, here’s a few further thoughts:

• By blocking time out in weekly (or longer) sprints, we have more flexibility … if we know it needs to be done or at least progressed by the end of the sprint and we’ve established which tasks are critical for that sprint, we have a clearer view of our objectives and can prioritise tasks that might fall outside of the sprint (or at least add them to the backlog). This might be particularly useful if there’s a lot going on outside the project or if multiple projects are running at the same time.

• If we add all tasks we’re working on to the backlog, then it’s easier to prioritise what we need to work on, thanks to drag-and-drop in the Backlogs view

• Azure Boards is a collaborative tool, so this makes agreeing on what’s a critical task for the sprint a lot easier, especially for team leaders and project owners

Ideally, a work item from a backlog allocated to a sprint is of a size that it can be completed in a single sprint. This forces you to think about the size of the piece of work you want to get done; going back to our music festival example, buying a tent is a good example of a task you can complete inside a sprint, but perhaps organising all of the gear you’re taking and might need to buy may be pushing it, especially if you have a job that takes up a lot of your day on its own.

Let’s recap quickly.  

• Sprints aka iterations are a term that refers to a series of equal duration periods, often a week or a fortnight, where tasks can be allocated for execution
• The tasks usually come from a list called the backlog, a set of project work items that are typically ordered by priority 
• Backlog items can be allocated to a sprint, but it’s generally preferable if you add items to a sprint that you can reasonably finish by the end of the sprint

That’s a lot to take in, so I’m going to park the rest of the discussion until next time. I’m sure you’ve already got questions, such as “How do I know whether I am likely to get my tasks done by the end of the sprint” or “what happens if I go past the end of the sprint with unfinished items” or even “what’s that fancy Boards item on the left hand menu”?  Nest time…