Within an agile project one of the most important tasks to manage effectively in order to ensure delivery of functionality by the end of the sprint is that of raising, managing and resolving defects in a timely and efficient manner. Outstanding defects can hold up the release of functionality to the business, denying them of the benefit of this feature and damaging the reputation of the team for being able to deliver an effective product on time.
Information in the form of feedback, either positive or negative, on any project can come from many sources, but what is particular about agile projects is that it can come from these many sources, at the same time. Whereas, say, with a traditional waterfall approach there is a defined timeline for when each stakeholder group gets to see and use the product, and provide feedback on it, with agile more people are involved at each stage of the development process, and the time between different stakeholder groups becoming involved is much shorter. Feedback therefore, can be provided that much more quickly also, so must be tracked very carefully to ensure that important comments about the product, critical defects, or new requirements are not overlooked.
Whilst agile does not encourage fixed processes, rather flexibility and regular communication, something of this importance does warrant some sort of formal management approach, as such over the last 12 months we have devised, and refined the following feedback and defect tracking process, which has been implemented on the previous project I worked on, and also my current one. Both are for the same client, one of the super-major oil companies, and the projects are very similar, one being a follow-up to the other for another business unit of the client. The locations however are very different, with the first project based in the UK, whereas the current one is based in the US, hence the working cultures are significantly different. It is for this reason though that I am confident that the process works, because I have seen it applied successfully in these two distinctly different work environments.
What the process diagram shows, is that feedback can essentially come from either of two areas; externally to the team, in the form of user feedback, which is most commonly fed to the BAs, or via a channel that the BAs manage; or internally from the team itself, most commonly as defects raised by the testers. Either group may provide feedback in the form of bugs, defects, enhancement, or just general feedback, so one of the first things the process asks the team to do, is to asses the feedback to determine what type of feedback it is.
Since this feedback is managed by two different groups within the team, with the BAs capturing feedback from users and testers from the team, it is important that these two groups coordinate, therefore regular meetings are held to discuss the latest defects and feedback. These can be held as often as required, so may be daily, bi-weekly, weekly, etc, but it is important that they are held.
Once an item of feedback is brought to the attention of the team, as mentioned it is assessed to determine what it is; a defect, bug, enhancement or other and depending follows a different route in the process outlined. Enhancements and general feedback will typically be taken and managed by the business team, with enhancements being updated into the product backlog, and defects and bugs being entered into the defect tracking system, in our case, Team Foundation Server (TFS). You may be questioning the pointing these two groups meeting, since they seem to come away from the meeting with the same feedback items they brought to it, but there are a number of important functions served.
First and foremost, it allows the swapping of feedback raised by one group, but which ‘belongs’ to the other; i.e. defects raised by users which need to be passed to the test team to be managed, and enhancements suggested by the test team, which need to be taken to the product owner by the business team to be considered for incorporating into the product backlog.
Secondly, both enhancements and defects may need to be prioritized, part of which will be dependant on how many of either type of feedback the team has to work on, and its current focus and workload. Neither group will know this completely; therefore it is essential that they coordinate.
Finally, meeting like this ensures that the team is as well informed as possible about the progress of development, how the users view the product, how they are using it, what kinds of difficulties the team are facing, etc, all of which aid more effective working.
The real strength of this process is in the fact that, whilst from the diagram it may look complicated, it actually makes use of already established tools. We already have a method in place for using TFS to raise and track defects, and we already have a product backlog in place for maintaining the work to be completed. Defining this process adds two things however; it ensures that all feedback is picked up on and handled appropriately, and it has helped us to tweak those existing tools. For example, we make the distinction between pre and post production environment defects, with those pre-production referred to as defects, and post production bugs. ‘Bugs’ are prioritized, whereas defects are not, but in order to distinguish them in TFS we assign the Bugs a priority 1, 2, or 3, and the defects a priority 4.
James