Estimating Tasks for Testers

It can be common for testers to find themselves rushing their testing work, especially when the developers only get to deploy user stories at the end of the Sprint. One way to mitigate this problem is estimating tasks. This is an exercise done by the development team during Sprint Planning. Task estimation is where they approximate how long it would take to finish tasks so that the development team can act accordingly throughout the Sprint. Because testing is a crucial activity in quality assurance, the testers must let everyone understand the effort needed to carry out their work.

How detailed should tasks be?

Before estimating tasks, it is important for the development team to agree on how granular their tasks should be for the user stories in the Sprint. They could be high-level tasks, such as “Develop a login page”, “Test login page”, and “Fix login page bugs”, or low-level tasks, such as “Collate SVG icons and images”, “Implement HTML/CSS/JS”, and “Create web services.”

Testers have a myriad of tasks themselves, including:

• Writing test plans
• Creating test cases
• Executing test cases
• Verifying fixes

Test deliverables can be big, and if the development team standard for task sizing calls for smaller tasks, they can divide these deliverables by creating a task for each section or test case. Some samples of low-level testing tasks include:

• List test approaches and test levels in the test plan
• Define test approaches and test levels
• Create test cases for User Story 001
• Prepare test cases and test scripts for regression testing
• Set up test data for testing

A good practice for making tasks more manageable is to write each task to take up a day or less for the task owner to finish. This allows each team member to match their tasks to the cadence of the Daily Scrum.

Task estimation best practices

 Task estimation can be challenging, but the following best practices can help the work be more manageable:

• Add buffer time to estimates – Some unpredictable things can happen during the Sprint. Adding some buffer time will help the team make time to recuperate when these risks do happen.
• Add more hours to spikes – Planning for spikes, especially for new or unfamiliar technology or functionalities, will help the team work around uncertainty.
• Take team capacity into account – The team must know everyone’s availability for the Sprint, so that they can adjust the tasks and estimates accordingly.
• Revisit past estimates – Looking at the Scrum board from the previous Sprint and learning from experience will help estimating more accurately for the next Sprint.

Tracking tasks with the Scrum Board

Once tasks have been estimated and committed during Sprint Planning, they should be plotted on the team’s Scrum Board. Typically, a Scrum Board would have the following columns:

• To Do – Backlog of tasks that are planned to be worked on but have not yet been worked on.
• In Progress – Tasks that are currently being worked on.
• Done – Tasks that are completed, depending on the team’s Definition of Done.

Some teams like to add other columns, such as “To Verify”, when there are tasks that need to be reviewed. Some teams also like to add horizontal swim-lanes, which divide the tasks by user story or by role. Aside from de-cluttering the Scrum Board, adding swim-lanes also helps in limiting Work-in-Progress (WIP) and ensuring that work will be done.

<– Continue Reading –>

Our Book Recommendations

We found these books great for finding out more information on Agile Scrum: