Azure DevOps Boards For Project Managers: Tips and Tricks

Nowadays there is a great variety of digital tools which help project managers and teams track their work, prepare different kinds of project information radiators and generate reports for key project stakeholders. In the IT corporate world you will probably have to work with the 2 most popular tools like Jira (Atlassian) and Azure DevOps (Microsoft). I had a chance to work with both of them, but in this article, I will tell you about Azure boards (ADO) and share useful tips which will make your life much easier 😁

How have I ended up using the Azure DevOps?

The first time I had to deal with Azure Boards was when I joined EY. The challenge I faced was that I had a new software development project to kick off 😲 and I had to learn ADO from scratch, absorb and implement new knowledge really fast. Time was crucial because if you don’t do a proper setup from the very beginning, later you may face many issues adjusting things, renaming stuff, or changing the structure of the whole board (trust me, you don’t want to spend your time like that 🙃). As you know, the later the change occurs, the more time-consuming and costly it will be.

Another challenge was that in that newly formed team no one had a chance to use ADO before, there was no specific standard or guidelines set yet on how to use it properly. So you can imagine that I had to take up a very responsible task – learn the tool asap, teach my team how to use it, define some baseline for them on how we were going to proceed going forward, then start using it as the projects progressed and continuously improve. Later it became much easier as more was learned, standards were applied across our department and we adjusted to the best practices which were shared later.

My journey to learn about ADO was amazing. I had to spend a few evenings on research and self education, apply the new knowledge in real project, learn by trial and error, communicate with many colleagues and learn from their experience and advice, check some courses on Udemy and internet etc. And the funny thing, believe me or not, I could not find much useful and structured information about ADO which would specifically be designed for Project Managers.

Now, after a year of using ADO, I have decided to share with you, my dear Project Managers and partners in crime, some useful tips and tricks about the tool. I’ll leave the technical side up to you on how to configure and apply my recommendations, but most importantly is that I will give you ideas. These hints are not only applicable for ADO, they are valid for Jira and other tools. Let’s get started 👉

Power is in the structure. What to consider at Backlog Level?

• On the backlog level consider the structure first. There are no strict rules which you have to follow when using Epics, Features or User stories. Combinations can be different: Epic- Feature-User Story; Epic – User Story; Feature – Epic – User Story. But you need to think and define with your team how you want to structure your backlog. Think about it with a top-down approach: the biggest chunks of work can be Epics with duration over multiple quarters, Features will be shorter and stretch over 1-2 months, User Stories have to be completed within 1 sprint. I used the following structure in my functional decomposition of the work: Epics – Features – User Stories.

• The naming convention for backlog items. In one of the Udemy courses it was recommended to define the naming convention upfront. I am so glad I took this advice and implemented this from the very start of the project. Why? Because as your backlog grows, it becomes more and more difficult to correlate User Stories with Features and Epics. If you have an Epic called “XXX”, the feature can be called: “XXX_YY” and the User Story can be called “XXX_YY_ZZ”. It will be also helpful when you create queries to generate information radiators, to filter specific information related to the work items. Believe me, I saved an enormous amount of time for myself and the team by implementing this from the very beginning. P.S. Make sure all your team members follow these naming convention rules or the whole effort will be in vain ☝
• Order and Priority column. I am a real prioritization machine. I do it myself and coach others to put everything in the order of priority (Epics, Features, User Stories). Backlog must always be a prioritized list of work to be done.
• Use start and target dates for epics and features. It will help you better plan when you plan to accomplish certain chunks of work and will use this information for release planning.
• Use the “Status” information column to reflect the state of each work item. Which Epics and Features are in progress or new, which are “under refinement” etc.
• Track the information about the amount of total “Story Points” and “Effort” (Sum of User Story Points) for each work item (on Epic, Feature and User Story level).
• “Sum of Tasks Original Estimate” and “Sum of Tasks Completed Work”. In ADO in column options, you have a roll-up column option. It is very useful to track the total amount of hours for each work item at every level. You can find more information under this link.
• “Assigned to”. This will help you track to whom the work items are assigned.
• I liked the column option for the “Progress by User Story” bar chart (as depicted in the picture above). It lets you see the progress status for each work item.
• I added the “Iteration path” column to be able to track which work item is planned for which iteration, quarter, or calendar year. The structure – is power 👌

What to consider at Sprint Level?

Once you have started with your Sprints Cycles, you need to ensure you have following configured use it.

• Sprint Goal. Do you and your team set a goal for each Sprint? If not yet – time to start. Product Owner will define what he or she wants you to accomplish, your team will tell you what they can commit. Once the Sprint backlog is negotiated over the Sprint Planning session, put your Sprint goal in writing and pin it on top of your Sprint dashboard.

• Sprint Capacity. Officially we have 8h workday. Of course, you understand, that nobody is productive 8h in a row. People take breaks, chat, participate in meetings and work on issues. On average the productive time for an effective team is around 6h. So if you do the math, you know that in a 10 days Sprint, the capacity for 1 team member is 60h. The maximum amount of work will be for this amount of time, if not less. And also we are all people, we get sick, we go on vacations, we tend to embelish the work we do. So you need to plan people’s capacity including their time off (planned and unplanned). Sprint Capacity is designed for that.

• Sprint Backlog. I had to ensure that the following is always considered:
  • User Story Order and Priority. Sprint backlogs need to be prioritized too. If there are any blockers, your team needs to know what they absolutely must finish, which items are of low priority, and can be dropped or moved to another sprint.
  • Use information radiators for User Stories: State (Active, In Progress, Done etc), to whom it is assigned, how many story points it is estimated, iteration path, tags.
• Sprint User Story Tasks.
  • Consider things like how many columns will you have to reflect the flow for tasks and bugs. From status “New” to status “Done” there can be columns like “Ready for Test”, “In Test”, “Ready for UAT” etc.
  • Think about information radiators on the cards for each task and bug which you want to be seen:
    • Activated date
    • Closed date
    • Original estimate
    • Remaining work
    • Completed work
    • Activity (testing, development, resolved reason (for bugs))
    • Priority
    • State
    • Use tags
    • Use styles to reflect different information with a different color (for example mark the card red if it is blocked)
• Use the “Work Details” option to be able to see how many hours are utilized for each team member and be aware of who still has some capacity or needs support.

As you have seen, there is a great variety of options that you can apply to manage the boards effectively, receive information faster, and act upon it without delays. I have prepared for you a small bonus in addition to this article 🎁 You can download it below. You will find there key project management tips from me which helped me and my team stay on top of things all the time.

I hope this information was helpful and you will be effectively using these tips and tricks in managing your Azure DevOps boards going forward. If you know someone who can benefit from this information, please share. If you have additional useful insights about ADO please reach back to me, I would love to learn about them. Let’s support each other in our mutual continuous improvement. Sharing is caring!