One of the most challenging parts of working in a software development team is field is learning the terminology. This blog post will focus on the terminology used by Quality Assurance and Software Testing professionals. Excellent written and verbal communication skills are extremely important to the job. In order for a team to be successful, everyone needs to speak the same technical language.
In a recent project, we hadn't clearly defined "done" and what it meant to everyone in the team. This quickly led to confusion by what anyone meant when they said it was done. A lot of "what exactly is finished in this and/or why did you set this to 'done' if you're still missing X,Y, and Z from this work item?" Once we established an agreed-upon definition, this didn't happen.
First, let's knock out some basic QA/Dev terminology with three important concepts: bugs, user stories and Product Backlog Items (PBI). During the lifetime of an agile project, you'll encounter all three.
Bugs are used to show not just where the problem is, but how the problem violates the requirements of a user story or PBI. A bug also includes important details like the steps to reproduce the error, so a developer can begin troubleshooting the issue.
A user story is a high-level, overall idea for a feature of an application. A product backlog item (PBI) is a series of prioritized requirements for an application during the software development life cycle (SDLC). PBI's are like a stack of to-do items for developers. A user story may generate many PBI's.
Here are some examples:
A user story may be as simple as: "As a customer for 'Buy my Stuff.com', I want to be able to sign into my account."
Product backlog items (PBI) are prioritized lists of specific requirements that are more granular and technical than a user story's requirements. An example of a PBI is, "The Sign-In screen needs to have Username and Password fields that are validated prior to allowing sign-in."
The Need to Define Done
First, I would like to mention that there is no exact definition of the word "done" when it comes to Agile Development. Neither a user story nor a PBI can be considered "done" until all associated bugs are "Done/Completed". Regardless of the methodology you're using, clearly defining what is meant by the terms "done" or "complete" can get confusing through the life of a project. What may seem like "done" to a developer may not be the same as what your QA team or Project Manager thinks "done" means. It's a best practice to always come to an agreed definition during the planning phase, before any bugs, user stories or backlog items are ever considered "done". The earlier this can be conveyed, the better.
On one project I was working on, the developers thought "done" meant that all the requirements of a PBI were resolved. I was considering "done" to mean that all bugs impeding the PBI were also resolved. We came to an agreement that "done" should mean "ready for end-user testing", not just "ready for QA". That's a pretty big difference!
A successful measure for "done", in my experience as QA, is defined as:
- Marking a bug as "done" means:
- The Bug has been verified to a state of working as intended/expected or otherwise verified fixed.
- A PBI or user story is set to "done" when all of the requirements are met. This means all associated bugs that impeded all requirements have also been set to "done".
As you begin winding down your agile project, all user stories or product backlog items should be set to "done" and confirmed having been implemented. Once all of the project's work is set to "done" the project is considered completed with all requirements met and acceptance passing.
If you want to see or learn more, watch this dialogue with Rally Software's Zach Niles about "Done" in agile development. The more you look up and learn about "Done" the more familiar with the concept you'll be and how important it is.
Want to learn more about Quality Assurance Testing and the Software Development Life Cycle? Sparkhound employs 50+ folks in our Application Development department and Project Management Office, and we work in large and small projects all day long. We'd be happy to discuss your quality assurance and software development needs.