Priorities of Work on a Board
This is obvious once you think about it but I’ve found many people haven’t thought about it so I’m going to lay it out here real quick.
A lot of teams use some kind of task or kanban board today to track the status of work. This is typically part of some kind of agile or Scrum or kanban process. If you want to learn more about kanban, check out my short course on the fundamentals of kanban.
Regardless of whether you timebox work into sprints or iterations or just have a continuous flow, you probably prioritize your backlog of work. That prioritized work is then pulled by (or, less ideally, pushed onto) team members to accomplish. The goal should of course be to deliver a quality result that solves the associated work item as quickly as possible.
Sounds good so far? Any questions or objections? Stop me now by leaving a comment below. You won’t actually stop me since I’ve already written this but knock yourself out…
What to Work On
All of the above is just to establish a common context for the next question: what should I work onright now? It turns out this is a question that team members need to ask regularly. Whenever they finish a work item, or whenever they get back to their desk after leaving for the day or having lunch, etc. Where is it most important to spend my time?
Sometimes, not knowing any better, the developer will just wait until the Daily Standup to ask what they should be working on. IMO this eliminates a lot of the value of having a prioritized backlog and a big visible board showing work status. These tools exist to ensure developers always know what they should work on next. More on this in a moment.
In some teams, work is assigned by some authority, not pulled by developers. In this case, it’s not really up to the developer what they should work on next. However, if the authority in charge of assigning work to developers takes into consideration the prioritized backlog, it should require little effort to decide what is the next most important work item.
Priority is Right
In a typical task board, work begins in some kind of backlog on the left, and proceeds through a series of steps left-to-right until it is finally Done or Closed on the right. Assuming the backlog is kept up-to-date such that the most important work items are at the front of the queue, then it’s a good assumption that the highest priority items on the board are in the rightmost columns of that board.
What this means to you as a team member is that you should focus on your assigned work items working from right to left. Get things that are almost done to Done before you take on more work. Help other team members get their work to Done if you can. Only pull in more work if you’ve determined that you have nothing further right and you can’t help anyone else’s work that is also to the right.
What Do I Work On?
So, you’re a developer on a team. You just moved a story from Active to Resolved. You’re waiting on another team member to review and approve your pull request. What do you do now?
- Help review another dev’s PR
- Help another dev with their active work item
- Work on unblocking work-in-progress
- Pull the next item from the backlog
It turns out this is pretty much exactly in the order you should do these things. It’s more important to review another PR to get it to production since that’s going to be closer to done (and to the right) than the next item.
If you can help another teammate get their work item to done, do so. That item is by definition a higher priority than whatever the top item in the backlog might be. Get it to done as fast as possible.
If there are work items, yours or otherwise, that are mocked as blocked, see if you can unblock them. Again, this will help get things moving forward and will ensure the highest priority stories are being delivered first.
Finally, if none of the above warrant your attention, pull the next item from the backlog. This should be the ultimate fallback, not the default behavior for this method.
About Ardalis
Software Engineer
Steve is an experienced software architect and trainer, focusing currently on ASP.NET Core and Domain-Driven Design.
