When a project backlog is turned into a repository where the majority of items are bugs, I like to think that we are then working under the premises of a Bug Driven Development process. Once this starts to happen you basically have 3 choices:

• Review your user stories, trace them back to the original business requirements and ensure you have enough information to develop the work products.
• Think about what caused the mess and try to fix it.
• Start using Bug Driven Development.

Ideally we would go for the first option in order to have a clear view on the scope for the current Sprint. This could work when a) time permits, b) the team realizes about the problem and c) your options to further enhance the requirements definition through additional elicitation and analysis are good.

The second option proves to be the most reasonable idea when it comes to retrospectives. But it might cause a significant deviation (in money, time or quality) after having spent a whole Sprint building tentative components that are potentially useless, or would need an important rework.

And the only option left is Bug Driven Development (bDD); not to be confused with Behaviour Driven Development. I’m not trying to convince anyone that using bDD is a good idea, since reaching this status means that not only several aspects of the analysis have gone wrong, but also that you are increasingly doing it wrong. You would use bDD to enrich your user stories from bugs encountered in the system being tested.

And this exposes a high risk: testers covering the gaps from proper requirements analysis. But it also proves the importance of having testers in your Agile teams. When I’m asked how does Agile approach change the traditional role of testers, my answer is: it does not! While Agile emphasizes the importance of involving testers in the definition of the user stories and acceptance criteria, it has always been a good practice to have the requirements reviewed by testers (and the rest of the team) to make sure these were accurate, testable, measurable and anything that define them as SMART. Same happens in other parts of the testing process. Test automation? Reporting? Exploratory testing? I feel most of these topics became popular during the last few years but things are not done differently in general.

So what about using Bug Driven Development? Let’s think about this scenario: third Sprint, the Product Owner has not been deeply involved in the process and non-business users are appointed to attend the demos and sign-off the incremental part that has been built, user stories are too high level, the business analyst was only involved during the initial Sprint and the rest of the team does not have a profound domain knowledge. It sounds bad, right? But I told you: if you are using Bug Driven Development, this is the result of many things done wrongly in the first place.

Let’s use the example of the diagram below and put in a timeline:

1. We have a business requirement which comes from the Project Charter or the Business Requirements Document, which defines the construction of a new interface to manually upload reconciliation files through sFTP. This is just a small part of the final solution and is targeted to be built as an increment on the current Sprint.
2. As part of the initial analysis, the BR is broken down into 2 different User Stories: one of them relates to the user authentication and the other one to the upload process.
3. While conducting the initial test design, the tester founds a lack of detail on the expected file extension which ends up in the addition of another user story defining the scenarios where it could contain zipped files of plain CSVs.
4. After running one of the test cases for the first time, the tester founds a defect and while this is investigated the team founds that a user could switch from the base directory and browse sensitive data. This raises a concern and ends up with the addition of another user story to define the directories restrictions.
5. The tester keeps exploring the system under test and founds something else as User Story N.

Some of these “discoveries” could have ended up as an enriched acceptance criteria, but the risk here is that an insufficiently defined requirement ends up with a significant amount of expectations in detriment of a very basic definition of its value or adherence to the business from a user point of view.

Obviously the sooner the user stories are enriched and completed, the less we will be using Bug Driven Development and the happier our lives will be 🙂