Estimating Agile User Stories for Testers Part 2

3. Pick a user story, then discuss its requirements, and acceptance criteria.

For the selected user story, the Development Team and the Product Owner come to an understanding and agreement on what should be done for the user story. This includes the goal and benefits of the story, the technology needed to implement it, and the criteria to meet for delivering within the Sprint.

4. Identify the tasks involved for the user story.

Planning tasks include listing what needs to be done in order to deliver the user story. It also involves estimating the time and effort it would take to complete the user story.

5. Estimate the story, according to the team’s chosen scale, and reach a consensus.

There are different scales for estimating. One way would be to use T-shirt sizing, where a user story can be categorised as XS, S, M, L, etc. Another scale that could be used would be the Fibonacci sequence. Everyone suggests what they think the user story size should be, and then discuss why. At the end of it, they must agree on what the final size should be, then move to the next user story.

During Sprint Planning, the team first discuss each of the user stories in scope, then the development team commit them to the Sprint Backlog.

Throughout the planning process, testers should be able to understand the tasks of the other members of the Scrum team. In turn, they must also help others understand the testing tasks. This way, they can come up together on the estimates for user stories.

Improving Estimates

It’s difficult to estimate user stories because they are abstract values, and are not correlated with the time needed to finish a user story. Rather, they depict the relative complexity and effort of a user story, which can make estimates subjective. Scrum teams often underestimate or overestimate complexity, especially when they are new to the Agile estimations.

Since there are different members within a Scrum team, each with their own skills, they could vary in opinions. Testers, for example, might not fully understand the lines of codes it would take for a developer to implement a user story. A data engineer might not take into account the testing needed for another user story.

Continuous improvement is part of any Scrum Project. Through learning from past Sprints, testers, along with the rest of the Scrum team, can discuss during Sprint Retrospective on better ways for estimating.

<– Continue Reading –>

Our Book Recommendations

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