We are a Srum team working in Agile, and we've always had only one field "Story points" that were considered as an estimate effort ONLY for the development, which is obviously wrong, as the QA work was not counted at all. I want to change that, and I've read that the Story points should be given after the discussion of the whole team, so developers and QA collaborate to decide the Story points for the whole task (including development, testing and even release). I find it a bit challenging for us, because it might happen that developers will "abuse" the big number in the Story points field selected for the task and give too little time for a QA, that is already working on two different projects and need to know (more or less) when the ticket will be passed to her. My idea was to divide story points for the Developers and story points for QA. It doesn't look Agile and I know that, but I am afraid we need this kind of control to avoid the mess. I would just like to hear some opinions, I have really little experience in the field, so any advice would be appreciated. Thanks!
5
-
1This smells like you are trying to control a situation through tools and processes rather than collaboration. Can you explain what "the mess" is you are trying to avoid? Why do developers "give time" to QA?– nvoigtCommented Jan 25 at 12:02
-
Unfortunately it often happens, that developers take more time working on the tickets than it's original estimate given during Sprint planning. We've discussed the issue during Sprint retrospectives but it didn't give long lasting results on the improvement of the situation. I am afraid that if we add to estimate also the QA work - it will complicate the issue even more.– user56958Commented Jan 25 at 15:29
-
1What do you mean "more time than estimated"? I thought you used story points?– nvoigtCommented Jan 25 at 16:39
-
yes, the story points given. 0.5 - is one day of work. 1 - two days and so on– user56958Commented Jan 25 at 17:02
-
1uh, that is not how story points work. The whole point of story points is that you don't assign a duration.– nvoigtCommented Jan 25 at 18:01
Add a comment
|
1 Answer
Estimates are not committments.
When we estimate on something that does not mean we should stop work when we reach the estimate. It means that we have attempted to guess at the size of a piece of work, but recognise our guess may be wrong.
The challenges you are facing are not related to story points. The challenges are:
Treating QA as a seperate activity from development - The whole team has responsibility for quality, not just your dedicated QAs. The developers write unit tests, they collaborate with the QAs on automated regression tests, etc.
Trust is crucial to a team - If you don't have trust then you won't have agility. Work on establishing trust in the team. Use transparency, avoid blame.
answered Jan 26 at 7:43
