How can I measure the effective team work per iteration?

Question

I have a team of 4 developers and 1 QA. My workflow in Jira is:

Backlog -> Analysis -> In Development -> QA Ready -> QA Complete -> Done

Every sprint (1 week) all issues get into QA Ready stage (QA member is not finishing to test all features in one iteration), also issues don't get burnt until they reach Done stage (deploy). So I am not measuring the effective team work per sprint.

Is it recommendable (for a story) to raise an issue for devs and another issue for QAs, so in a sprint I can only include the issues that will be "Done"?

For this, I will have to change my workflow to:

To do -> In progress -> done

So this way, analysis issues, development issues and QA issues will have a shorter lifetime but they will be burnt and measure per iteration.

I don't like this solution, because there will be 3 times more issues.

The thing is that burndown-chart is not showing what the team is working, even when I defined to set resolution when the issue gets to QA ready stage.

Answer 1

But you are measuring the effective work per sprint just fine. If the team delivers development work but not QA for a few stories, along with some analysis, but nothing else, then the effective work for your team for that sprint is zero.

Because nothing of value has been delivered to the customer, and that's the value of a sprint. Not the "story points", not the amount of code, not the number of ideas or sketches, not the number of excuses. The only thing you should be measuring that has value, is the number of actual, tested, verified, working features.

Trying to measure story points for things that don't deliver value is just gaming the system. All it lets you do is avoid the actual problem in your workflow, which is that stuff isn't getting done. The only thing Agile does is show you where the problems with your way of working are, it does not solve your problems. Shoving it back under the rug by measuring things nobody cares about (like story points on things that don't deliver customer value) won't help you get better in any way.

So you don't have a problem with measuring the team's effective work here. You have a problem that the effective work is really low, because the burn time on your stories is very high. You need to try and fix that, probably by slicing stories smaller, and getting the whole team involved earlier. Get your team involved and work with them to find ways to complete the whole story within the week.

Answer 2

The fact that only a small number of stories get completed during a sprint shows a dysfunction of your process and/or team, but it is highly questionable if splitting the stories in "dev stories" and "QA stories" is really going to resolve the dysfunction.

The aim of a sprint is scrum is to deliver a potentially releasable product increment. A potentially releasable product increment is an improved version of the product that is ready to go live from a quality viewpoint, but there might be business reasons to delay the deployment.

If you find that lots of stories remain in the "QA Complete" state because they can't be deployed due to business reasons, then you might consider taking the deployment step out from the Definition-of-Done (i.e. the story gets burned once it reaches QA Complete).

If you also have the problem that the testing can't keep up with the development, then you might have to look at your development practices. You mention that the team has 4 developers and 1 QA member, but the entire team should be responsible for completing the stories. If the QA phase is a bottleneck for completing stories, then you should discuss with the team how everybody can pitch in to get the testing done faster, which could mean that the developers also need to take up some testing activities.
Also, the QA member should be involved in the stories from day one, and not only when the developers think that the implementation is done.

Answer 3

First and foremost: avoid breaking down tasks by teams. Based on my previous experiences, it was always painful to put the pieces together retrospectively. So no, avoid the urge to create different tasks.

Based on your example above, you have two different teams (development and testing) working over the same deliverable.

Assumptions:

• You are using jira statuses for each team
• Each team has a specific board
• Your burndown is configured to burn by story points

Fastest solution:

• Burn by remaining time

Better solution:

• Either avoid the usage of iterations and go back to waterfall (there's no problem on doing waterfall nowadays) OR have a single iteration covering the work (as mentioned by John_C on the comment).