How Agile/Scrum Teams estimate Testing Effort?

Question

In Agile Testing, what are some of the most common estimation techniques with context to the QA process. What are story points?

Answer 1

Agile teams are cross-functional teams. They estimate the work from design to delivery often on a story based level. This includes the testing work, since testing should be part of the definition of done.

Story points are the relative size of the complexity of the task at hand. Read more about estimating with relative sizes in this blog.

I as a tester part of an Agile team always sit in with the planning poker sessions and estimate just with the team, keeping in mind the complexity and size of the testing efforts needed to complete the story to done. If I know the area we are working on lacks a lot of automated test coverage I will give the story a higher estimate then the programmers in our team, often we average out the points in these cases.

Answer 2

Firstly unlike traditional methodologies where the QA estimate may be separate to the developer estimate, when working in an agile way you will want your software testing estimates to be combined with your developer estimates, producing one estimate per user story.

The most common way to do this estimate is using story points where your estimates is a combination of complexity, technical risk, effort etc... rather than time.

Planning poker is the most common technique, but there are many others.

Overtime you will then get to know your teams velocity and this will allow you to predict how many story points you can complete per sprint. As your team start to get used to working together and whilst on the same project, you should also expect your velocity to increase.

Answer 3

We use to do gather as a team for Sprint Planing meeting(Where we decide, what can be delivered and which user stories to be delivered first/last in a sprint)Our sprint is for 2 weeks duration.

Scrum master will be ready in Sprint planing with any planned leaves from key resources and any Public holidays coming in a sprint etc and will decide the Total Team Effort.

Including tester's, BA, Dev's everyone will gather and it's Scrum Master turn to explain each user story with Acceptance Criteria of completing it on Digital screen.

Then Dev's, Tester's will discuss on the flow about the effort involved or any dependencies etc.

We play "Planning Poker" game to give individual estimates which are called story points. We decided that 1 point = 1/2 day work every company has their own definition of a story point.

Finally, after noting down every individual story points scrum master will come up with Actual Story point (which is the most common Estimate given by the team members)

Let's say PersonA thinks it's gonna take 2 points PersonB- 3 Points PersonC- 3 points PersonD- 1 point PersonE- 5 points

Then the most common estimate we got from team is 3 points so this will become the Estimate for the Story.

Answer 4

In addition to utilizing Story Points, our team logs time on each task

Then we can easily compare historically how much coding vs testing time has been logged relative to story points

This way we have a baseline and can create co-relation between small/med/large story points and relative coding vs testing ratio

Example: large stories (>21 points) tend to have equal testing vs coding efforts while small stories have testing effort as 30% of coding effort

These insights are then used to give high-level guesstimates when meeting with management to revise roadmap and when to expect things to be delivered

Answer 5

1. Identify base stories.

   • It is very important to identify one or multiple base or reference story against which you would do relative sizing of the backlog. This story is picked from current product backlog or a different story which we have done earlier. But what is important is the understanding of this sory is same among everyone on the team. Team should be confident of this base story.

2. Talk through the requirements of the story.

   • Product Owner or Proxy PO, will answer questions and provide explanation about what exactly this story entails.

3. Discuss and jot down things you want to remember when implementing this story.

   • These can be bullet points on the story card or text in the “notes” section of a tool. This is best done by Scrum Master who can add these details as and when discussions are on.

4. Some of these questions team ask themselves when they start sizing.

1. Design: What will we have to learn before we can start work on this story?

2. Coding: How much code will need to be written for this story? Have we written similar code before?

3. Unit Testing: Will any special setup (e.g., mock objects) be required to unit test this story?

4. Acceptance Testing: How much work is involved in helping the customer to automate the acceptance tests for this story?

5. Integration Points: Does this story have external dependencies?

6. Expertise: Does anyone of us have done similar story before?

5. Find some point of relative comparison.

   • If this story is about the same amount of work as one you have already sized, give it the same number of points. If it is more difficult, give it a proportionally higher value. If this story is similar to another but less work in some way, give it a lower value.

6. Reach a consensus among entire team present as to the size of the story as per definition of done.

7. Validate that your estimates are internally consistent among stories as you go along.

8. Periodically ensure that all of the 1’s are about the same, all of the 2’s match, etc.

   • Likewise, the team should agree that a four-point story is roughly twice as much work as a two-point story.