Include QA's time separate from Developers time

How reliable is the team’s estimation method proving to be?

In my team, we also have separate estimations for dev and test. I also was not used to this but in present scenario, it make more sense to have separate estimations for DEV and Test.

I am assuming that your team has dedicated testers and developers having different responsibilities. So in this case they require to inspect and adapt their individual estimations and story points. But giving half of developers story point is a wrong method. Sometimes i ask testers to give their estimations first on the basis of the scope of testing. They discuss among themselves and comes with a story point. I then ask developers to give their estimations. 

When i started working with this team, i used to encourage them to discuss the scope with other team members and many times the scope used to increase or decrease.

When it comes to estimation, we tend to overcomplicate it, and it can be beneficial to consider whether what you're doing is helpful.

What do your team want to get out of estimation?

I personally see 4 main benefits, but the team should first work out what it wants estimation to achieve.

The main benefits I see are better forecasting (for POs and dev teams), helping the PO with prioritization, identifying misunderstandings of scope, highlighting the need for items to be broken down into smaller deliverables.

Once you know what the team wants to achieve, you should consider whether these estimates help, and whether a simpler technique would be sufficient.

In the current team I'm working with, QA's are estimating their time after/seperate from developers.

You might also want to explorer whether this is the behaviour of one cross-functional team, or two teams that hand off from one to the other.

Sounds a bit like a mini Scrum-fall. How is transparency impacted when going from dev to QA? Is the estimation still unanimous if different estimations are combined with a relative share by different groups?

Hi , 

Can I confirm that QA should be estimating with the development team as 1 estimate, rather than estimating separately please?

>>As Scrum Guide puts it - 

• Scrum recognizes no sub-teams in the Development Team, regardless of domains that need

to be addressed like testing, architecture, operations, or business analysis; and,

• Individual Development Team members may have specialized skills and areas of focus, but

accountability belongs to the Development Team as a whole.

@Sebastian - We had similar problem in my team initially that QA used to provide additional points along with developers to each PBI and then we used to add them.

Leave about the estimation , we realized this encouraged a mini waterfall within the scrum. We were not utilizing one of the core aspect of scrum of having cross skilled members in one team. Now, rather than working in individual units (I shaped people) we encourage team to have more collaboration at all levels and utilize the opportunity of getting cross skilled ( move towards T shaped). SM should foster this behavior of getting people to collaborate more and learn from each other. And after some time this sharing of knowledge and collaboration directly impacted our estimations. Eg - Developer estimates including testing, tester highlights the possibility of risks and complexities that developer might face. 

As Geoff Watts put it nicely in his book Scrum Mastery 'keep doing things you do, learn something new, and teach the other' !!

As per me estimations should be focused more on forecasting of 'work an item needs to be Done' at the end of sprint. I totally agree with @simon . But forecasting can be wrong , it will only get better from team's experience. 

Focus should be more on getting the tasks done than having perfect estimations. I just highlight this to you because i faced similar issue and after a lot of analysis found the root cause to be something else. :-) But not necessary that you find the same problem in your team.

Having Dev and QA estimate separately is Scrum-fall as others have pointed out. I am going to assume from this that the Developers write code for 2/3s of the sprint and then QA will test it in the last few days of the sprint.  How often are problems found in the last days that can not be fixed by the end of the Sprint?  And if so, how does that affect the ability to deliver a potentially releasable increment?

As others have said, I'd be coaching the team on being more of a combined team instead of silos of work.  Sure, they should be a self-managed, self-organizing team and choose to segment like this.  But there is nothing to prevent them from having a story finished on day 3 of the sprint that can be tested and finished by day 5.  That is what I would focus my initial efforts on coaching the team.