Estimating Agile User Stories for Testers

In Scrum, testers are not a separate team who just test the application being built. Scrum teams are cross-functional, and developers, analysts, and testers contribute their time and skills to work together on completing user stories and the product.

What Testers Need to Consider When Estimating

The following factors need to be considered when testers estimate user stories with the rest of the Scrum Team:

1. Amount of work

Like other team members, testers have a variety of tasks in a Sprint, including test setup, test execution, and defect reporting. But the amount of effort needed for one user story will differ from another. For example, testing a user story about a login page will differ from testing a user story about a sign-up page. Both pages have different fields, the latter having more fields to fill out. Aside from understanding what needs to be developed, the work that goes into developing the user story must also be understood.

2. Complexity of work

User stories will also vary in the complexity of implementation. There will be varying scopes of testing work needed for each user story. Testers need to be able to plan the different ways to test each user story, as well as the scope of each user story. An SSO login page could be more complex than a regular login page, even if they share similar purposes of logging a user into the website. They could differ in implementation and technology layers, so the test scenarios and approaches could also differ. The acceptance criteria of a user story will also give insight to complexity, so testers must also consider them in their estimation.

3. Uncertainty of work

Because Sprint Planning and Product Backlog Refinement entail planning for features that are yet to be developed, risks and uncertainties need to be taken into account during user story estimation. Will the team be using a new API? Is the user story similar to something that’s already built before? The more uncertainties there are, the larger the estimation should be.

Aside from these factors, testers should also adhere to their team’s Definition of Done is. If the Definition of Done includes testing user stories in different environments, then they must take that into account when coming up with estimates.

User Story Estimation in the Planning Process

User story estimation can be done during two Sprint ceremonies: Sprint Planning and Product Backlog Refinement. Sprint Planning is for deciding on which user stories to be committed within a Sprint, while Product Backlog Refinement is for discussing and clarifying user stories in the Product Backlog that will be developed in future Sprints.

Both ceremonies involve planning user stories, discussing their details, and estimating their sizes, as the Scrum team collaborates with the Product Owner on creating, modifying, and splitting user stories. Ideally, user stories have already been sized or estimated prior to Sprint Planning, but those estimates can be changed when the Scrum team negotiates with the Product Owner. Estimates will also change when user stories are being split.

User story estimation, as part of planning processes, would typically be as follows:

1. For teams with completed Sprints – Have a base user story ready for comparison.

Even though user stories will be unique from one another, there could be similarities in terms of implementation and complexity. If the team has already developed user stories in previous Sprints, they can pick a user story and can use that as a comparison for estimates.

2. Scope and list user stories for discussion.

There will be a list of user stories for the teams to discuss, for Sprint Planning, it’s scoping the user stories that they will commit to finish for the Sprint.

<– Continue Reading –>

Our Book Recommendations

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