Put simply, if QA is not part of story pointing, your “definition of done” is broken.
Is QA a regular in your story pointing meetings? I sure hope so.
If they aren’t, you probably are:
- optimizing for development instead of delivery
- carrying over a lot of work from sprint to sprint
- finding more bugs in regression than you should
- increasing your development risk unnecessarily
- taking longer and longer to complete testing each time
Optimizing for development instead of delivery. When this happens, your measures, process, and focus is missing the boat. You can somewhat plan and give answers regarding the development of something, but you don’t really have a grasp on how long it takes to deliver that work and realize the value and benefit it is meant to provide. There’s a lot of work that is not being considered and planned for appropriately. This leads to lots of guessing, crossing fingers when releasing, frustrations, and unfortunately a big gap in an important area you want to improve upon.
Carrying over a lot work from sprint to sprint. Because QA work is not being considered and planned for appropriately, it almost always results in stories piling up at the end of a sprint and being carried over to the next sprint in order to be tested. The sprint was filled with stories that keep the developers developing, but the stories all piled up at the end of the sprint. But no worries, they are “done” with development and only need to be tested. Sadly, the next sprint is planned again with those as “done”, so another full load of stories is given to the developers and it just gets worse. Worse, because now your dev team has a full sprint of development work planned, but they spend the first part of each sprint helping with the testing and bug-fixing the stories before, and the planned work is immediately getting delayed in starting. And so it goes and goes.
Finding more bugs in regression than you should. Despite the sad reality described above during development, eventually stories again are called “done”, after being tested at the story level, and then regression testing is started at some point only to find more bugs. Why is that? Because the story was discussed for development without all perspectives and it isn’t until regression are some of those other perspectives proven. So again, it goes back to the developers for more fixing.
Increasing your development risk unnecessarily. We’ve touched on this risk indirectly above. Whether it appears as missing deliverables, increased bugs, or delayed deliveries, you most assuredly have unhappy, frustrated developers that are not being successful in your eyes and especially their own. In the end your customers will feel it. Another way you’ll feel it is when your developers leave for another job opportunity.
Taking longer and longer to complete testing each time. Just like development tasks, testing tasks get stacked up, and with every story your regression suite only increases. And since QA conversations of risk for a story aren’t being had, you just try to test everything each time. That’s a clear recipe for long and ineffective testing.
But what if we don’t even have a QA person on our team yet?
Everything still applies, and I’m sure what was described above is all too familiar. I’m sorry you don’t have a QA person yet to help bring other perspectives, keep the team honest (conflict of interest), and provide a more focused skillset in such an important part of the work needed to deliver value and not just code functionality; but until you do, it is on the team to not forget to put on your “QA hats” for a moment during story pointing.
Pointing will indeed go faster if you skip the QA perspective. But your work will go slower.