Can 'QA approved' count towards your team's definition of done?

Question

I'm a ScrumMaster running a development team using scrum. We are working in 3 week sprints and at the end of the sprint we often do not release our code to production right away. It could be a number of weeks before the PO passes the code in UAT and sets a deployment date.

In order to count the 'done' story points and calculate velocity the team has been counting anything 'QA approved' as 'done'because the development work is completed.

Has anyone worked in a similar way, or believe this is the wrong way to count our completed effort?

Any advice on how we should measure progress and 'done'?

Much appreciated!

Answer 1

The definition of done should be something that your team can do. Having external dependencies in a definition of done is a nightmare.

If you want to test your story thoroughly, which is great, you need to have a resource on your team that can do that. Your team is supposed to deliver a final increment of the product. Delivering an increment that is not done is the antithesis of Scrum.

So if your DoD contains "QA approved", you need to have a QA resource on your team that can do the approval in your sprint. Because otherwise, your stories will inevitable end in "...and we haven't heard back from QA yet." because they are on their own timetable.

Answer 2

One of the big advantages of using Scrum is that it makes true progress visible. By having a definition of 'done' and by looking to have a potentially releasable increment at the end of each sprint the progress of the team is very transparent.

If you have UAT outside of the sprints then progress will be unclear.

As an example, say the team has 5 stories done at the end of the sprint. A few weeks later when the stories went through UAT some serious problems were found and the team had do a lot of rework. It is clear that in these circumstances "5 stories done at the end of the sprint" has little meaning.

My recommendation would be to try and do UAT as a part of your sprints. This can be a challenge, but it is usually possible.

One thing that helps is to get a commitment from your Product Owner that they will be available for a certain amount of time during the sprint.

Another thing that can help is to have pre-booked 'slots' in the Product Owner's calendar when they know they will receive stories to be tested. For example, one team I worked with had a 2-hour slot in the Product Owners calendar every week on a Tuesday. The Product Owner new to keep that time free as they would be expected to do UAT during that time.

Answer 3

It can. But its a bad idea.

Unless you are veing very strict about the acceptance criteria QA means adding features to a product.

Therefore if you cant mark a feature done withput passing QA you will be changing requirements on the fly.

QA should be part of the iteration of design, feeding features and bugs into future sprints. Your acceptance criteria for a feature being done should be static and not include a human judgement component.

That being said. It is quite common to do testing or QA 'in the sprint'. My view is that this comes from a waterfall style expectation of 'done'

Embrace the idea that a 'done' feature is just an iteration and not a final product. You will have changes you want to add. You can wait two sprints to get them.

Answer 4

We always use "QA approved" as the definition of "done".

Deployment is often a sprint of its own, if it's big enough, since we first deploy to a staging server and the have a gradual roll-out.

Answer 5

With the comments in the question, the PO is not available to confirm if an increment or feature is successfully added to the Product. Also, you are not delivering the product after each Sprint. Your Sprints are focused towards adding new features & fixing few older issues in different features of the application. Here you have few points to consider for different Scrum Ceremonies with the PO and the team members:

Backlog Grooming Meetings -

• Ensure the meeting is regularly done.
• PO have his Top 10 priority Stories on the Top of Backlog for the Team to discuss.
• During the meeting encourage the team (Dev & QA) to ask questions about Story and get as many tasks added as needed (to a Story) with DOD & Scope of the Story and different tasks.
• DOD should be defined by PO, For DEV, say (adding a page with the mentioned features. DEV team could have an analysis task for the same and share a document on the way implementation would be done to the PO and Team). For QA, say (DOD would be "Environments to be Test the feature, Creation of Test cases). Adding Bugs in the bug tracker".
• Any newly introduced bug related to the feature should be fixed as the part of the Story and a broken feature should also be fixed.

It is only after this you could mark a Story as done to calculate the velocity of the team. Ensure, the team does brainstorming before assigning Story points to stories. Else, incorrect velocity would be calculated.

Daily Standup Meeting -

• Keep the Meeting Short and crisp with the teams focus of the completion of Stories, raising impediments.
• Work to resolve the impediments.
• Do meetings with the PO and team (if needed) for any queries from the team. Ensure the meeting has the right attendees.

Sprint Demo -

• Ensure Sprint Demo is done for the maximum Stories of the feature.
• PO and other Stakeholders attend the Demo. Record the Demo to be shared with the team and get an approval from the PO after the Demo on a specific Story.