The role of a tester in backlog grooming and planning

Backlog grooming

As an on-going activity, the product owner and the scrum team should be actively reviewing their backlog and ensuring the work is appropriately prioritised and contains clear information. This allows each piece of work to be more easily planned into a sprint as it can be more accurately estimated.

As a tester I actively try to be involved in this process as it is my first opportunity to assess the requirements and the information provided. It also allows me a chance to gather information required for testing, which allows me to provide more reliable estimates.

The objective is to be in a position where for any piece of work presented in planning you know exactly what the work requires. You should then have a good idea of what you will test and therefore provide reliable estimates. If this is not the case, then the work cannot be effectively planned into the sprint.

Planning and estimation

At the start of each sprint, you have a sprint planning meeting. In this meeting the team collectively decide what work they can commit to being done by the end of the sprint. This may or may not have an estimation process. This is your last opportunity as a tester to ensure that you have all of the information you need before work is started. If the appropriate backlog grooming has been done, then this should be a relatively straight forward process, however inevitably there will be pieces of work that need clarification or may have missed something.

Some example typical thoughts I have in a planning meeting for a piece of work are as follows:

• Do I understand the requirements?
• Does everyone else understand the requirements? (and does their understanding match mine?)
• What requirements have not been written down?
• Are there any external factors such as legal requirements or third parties?
• How can I test this work? Is it even testable?
• Do I need any additional tools to test this work?
• Do I have any dependencies in order to test this work, such as needing live data or having to work directly with a customer or third party?
• Does this work conflict with anything else in this sprint?
• Does this work conflict with work being done by other teams?
• Are there any repetitive checks that I could automate for this work?
• Do I need to consider other forms of testing such as security or performance testing?
• Is the balance of development workload to testing workload viable?
  
  

Hopefully I should have asked most of these questions during backlog grooming, and I wouldn’t always ask all of these questions, it very much depends on the context of the work. But hopefully this demonstrates that you can easily think of a lot of questions and it is important to ask these before and during planning.

Once you have the answers to all of these questions, you should have a good idea of what you are going to test. From this you can provide a more reliable estimate of how much testing you would like to do. Not only should you have a good idea of how long it would take, but also you should be better equipped to analyse risk.

Summary

• Planning a sprint is easier with clearly defined work and when the team has prepared for the planning meeting.
• To achieve this, backlog grooming should be used to ensure tickets are prioritised appropriately and contain enough information.
• Backlog grooming should also be used to prepare for planning such as considering if you need testing tools or environments.