How and why you should regularly backlog groom and re-assess priorities

To ensure that you are always focussing on the correct areas of your product and business, it’s vital that your “Product Backlog” is groomed regularly and your priorities are reviewed. I run a weekly backlog grooming session with some of my team but for me, it’s a continuous process that I’m doing myself daily. Before I run through how and why I do this, let me first explain how our backlog is laid out with a simple representation of the board:

Product Backlog

There are six columns that represent the life cycle of a project:

  • To discuss: Projects in this category have not yet been fully discussed or approved, they will remain here until gone through in our weekly meeting (unless of course they need urgent attention)
  • More info required: These projects have been deemed not thought out thoroughly enough to be prioritised or have work started. Investigations are required before we can comfortably make a decision
  • Accepted: Projects which have been investigated, are 100% ready for a team and could be started on if resource were available
  • Next: This column holds projects which are next in line for teams to begin, projects are put into this column when I know that the team will soon be complete with their current project and available to start the next
  • In development: Does what it says on the tin — projects which are currently in development
  • In testing / ready for deploy: This final column is where projects which are going through final testing processes and are imminently ready for Production can be found

There are then six priorities which a project can be given. These are as follows:

  • Un-prioritised: All newly raised projects are entered as un-prioritised
  • Must: Saved only for projects which are critical and of the highest priority, security updates being a good example of this
  • Should: Projects which are important but not critical such as removal of tech debt
  • Could: Projects which are desirable but not necessary which may include tasks like updating front-end styling
  • Won’t: Projects which have been agreed by all involved that simply are not required, perhaps due to an expected negative outcome/experience as a result of doing it (Note these are still visible in the system but not shown on the Product Backlog)
  • Someday: Projects which are deemed not appropriate at the time of them being first raised. Note that this does not mean they cannot be re-raised at a later date when it is more appropriate. Projects can be marked as Someday for a number of reasons including the estimated amount of work involved being far more than you have resource for at that time (Note these are still visible in the system but not shown on the Product Backlog).

I try to ensure that this board representing our “Product Backlog” only contains projects which are either already in progress or that we will be able to start on within the next 4–6 weeks maximum. I do a daily check of which stage of the workflow each project is in, look to see if any should be moved forward (or backward) through the workflow, if there are any outstanding questions/comments from the team on them and if there is anything misallocated.

Backlog grooming for me is a continuous process so that I can ensure the board remains a clear and concise view of our current focus, that it is easy to read and the workflow easy to understand. Anybody looking at that board, including myself, should be able to do so confidently knowing that it is an accurate representation of my development team’s workload. By keeping on top of my backlog, I am able to allocate resources accordingly as I know who will be free approximately when and I am able to line up their next suitable task ready to go.

Re-assessing the priorities of your Product Backlog is required often so again, you can ensure that you are always focussing on the correct areas of your product and business. A project doesn’t have to stay the same priority it was assigned when first raised, it’s perfectly natural for it to become a higher or lower priority depending on circumstances. For example, a known issue which only happens once every month may be prioritised very low compared to other work however if it then blows up and starts happening once every minute, it suddenly requires escalating higher and looking at urgently.

Whilst I manage one main Product Backlog for the development team as a whole, I technically within that also manage two smaller Product Backlogs. I am DPM for two Scrum teams who both work in two week sprints, starting on alternate weeks and they each have their own Product Backlog. I re-assess the priorities of each team’s backlog before the end of each sprint so that every new sprint started is done so on the correct terms. Team priorities can change between sprints for a number of reasons such as but not limited to:

  1. A live issue with payments has been discovered and a fix is required urgently so jumps to the top of the queue. Ongoing project work will need to be put on hold until this is resolved and users are able to successfully make payments again
  2. A project which was of a lower priority last sprint is dev complete and now only requires testing, documentation and deploy. This may be brought higher up the priority list to get out the door early on in the next sprint to ensure that the code isn’t left too long before test and deploy. This avoids having projects and PR’s open for longer than necessary, reduces the need for the code written to be rebased and potentially also rewritten against Master due to other releases that have gone out in the mean time

For me, a project is not complete when the development is complete, it’s not even complete once it’s been deployed to Production. A project is only complete and therefore moved off the Product Backlog once the development, testing, release and any automation and documentation tasks are also complete. Automation and documentation tasks should never be an after thought left on the back burner to be completed as and when people are light in between other projects (spoiler alert, people are never light in between other projects) — they are just as important as the manual testing and deploy. Only once all tasks are complete, can a project itself be considered complete and the team allowed to move on.

By re-assessing priorities each sprint, teams are able to concentrate on only the most important projects and remain commercially aware whilst still being able to complete and ship work. As explained in my previous article, our teams are cross functional and encouraged to work together and learn from each other on projects where possible. If a team member finishes their work on priority A, they simply move onto helping others with priority B. However, if they are unable to or not required to help with B, they can move onto starting C instead with the understanding that others who are working on A and B, including QA’s, will not be fully available to help them on C.

Continuous backlog grooming and re-assessment of priorities benefits everybody in the business in one way or another. You as Project Manager are able to ensure that you and your team are always focussing on the correct areas of your product and business. Staying on top of where each project and team are at is a far easier task because of this and allows for clearer project allocation and management. Your development team is safe in the knowledge that they are commercially aware, working on only the most important tasks and not rushed from one unfinished project to the next. The wider business trusts that the correct projects based on business need and criticality are being worked on in the correct order and can receive accurate status updates as required. Everybody wins.

Backlog grooming like a boss.

If you liked this story, please share and recommend to others. There’s plenty more where this came from!