Whether it is pure SCRUM or ScrumBan, it calls for the use of user stories to represent the specifications. A user story is a high-level definition of customer requirement and has to be “just-the-correct” size. It should be sliced small enough to be completed in short time period and large enough to deliver appreciable amount of work. Estimated based on story points (or relative estimations for mature enough teams) and the progress being tracked down on electronic walls / physical walls, user stories help calculate the team’s velocity.
All sounds nice and easy if it is only user stories that move across the wall in swimlanes, but it gets complicated when bugs come into picture. There are several ways to represent bugs on the AGILE Wall and all of them have pros & cons.
1) Creating bugs as ‘bugs’ and adding a card (on physical wall) or ticket (in Systems like JIRA).
It seems like the simplest way to add a bug to your wall but lot of teams (or people within the teams!) do not agree with this approach!
— Idealistic SCRUM followers will not agree to adding bugs as ‘bugs’ on the wall during the Sprint as manually adding anything during Sprint is ‘Scope Change’. This statement itself is a topic of discussion for parties with different interests. As a tester, I completely disagree that bugs are “out-of-scope” things and I believe they need to be fixed for stories to be considered as Done.
— You need to make sure there is a way to link bugs with corresponding user stories and they are not orphans on the wall.
— There can be numerous bugs as compared to User Stories and if that happens former will predominate the wall. Again, some will argue if the number of bugs is potentially high, something went wrong with splitting epics as user stories!
— Its challenging to maintain a burndown chart with this approach as the original estimates are on the user story which included bug fixing time as well. Everytime a bug is created, you need to estimate it and take the time out from the user story estimate, else burndown chart will give crazy results.
— Gets worse if there are multiple bug cards for a user story lying in different lanes. Some bugs will dictate the user story to be in “To-Do” Lane while others will want it to be in “To Be Tested”. It again contradicts whether you can perform testing if the card still lies in the “To-do” Lane or can you re-work dev work if it is “To Be Tested” lane.
— User Stories v/s Bugs is considered an important Metric by some teams and this approach makes it easier to obtain it.
2) Re-opening or moving a User Story to “To Do” swim-lane every time a bug is found.
Another approach which too has different schools of thought. When a bug is found, move the user story to the left side of Wall. Sounds so simple, but there are hiccups.
— It works better on electronic walls as you can add a comment on the user story, change the status and it moves back. For Physical walls, adding a comment on the index card doesn’t work, you need to create a new one and find a way to relate them to each other (symbiotic cards they are).
— As number of bugs increases, it might just mess up the wall, both electronic and physical.
— What if you run the first test case and the story moves to “To Do”. You might want to run other non-impacted test cases, won’t you as a tester? But the ball is in Developer’s court once the card moves!!
— The burndown chart will be flat for most of the sprint and spikes at the end, which does not sound very good.
3) Adding a bug as separate User Story
Actually found from the web that there are some people /teams who do this.
— Ideally, one can not add a user story to Sprint backlog within a sprint. So, this seems like an outright wrong approach.
— Burndown chart and velocity faces the same issues as pointed out in #1.
— Practically, sometimes some bugs call for more investigation and reveal things which were not accounted for during development and yes this is not very rare astonishingly! Such things better got to Product Backlog rather than being included in the Sprint Backlog.
4) Adding Bugs as “sub-tasks” under the user stories.
This approach seems like another obvious one and I prefer it personally.
— For Physical walls, you can create a separate card and associate it with the user story by some means, keep the User Story in “In Progress” and keep moving the bug card until it is complete. For electronic walls, adding sub-tasks is without any hassles as well.
— It keeps the User Story clean, provides for better visibility of associated tickets/cards under the user story.
— Burndown chart maintenance will still be a problem.
5) Creating a separate User Story as “Bugs” and adding all bugs under this user story
Not sure if this the best way mainly for following reasons:
— How can you estimate for this user story during Sprint Planning unless you can accurately predict the number of bugs expected.
— Tracking down the bugs with respect to user stories is difficult.
— This user story might never be delivered if few bugs (minor maybe) could not be handled within the sprint.
— Acceptance Criteria for such a user story is a sure challenge.
6) The Most Agile Way
If it is a minor/trivial/cosmetic bug, doesn’t need to be recorded. Can be fixed without any fuss just by better communication and collaboration between testers and devs. Team has to come to an agreement on what to log and what not to log!
— It works well in very mature teams only where there is lot of trust among the team members.
Most people find it difficult to accept this strategy and people are just so emotionally attached to documentation!!
— Doesn’t work well for complex systems where something fixed in this sprint might impact something else. It might be excessive overhead to track it down later if bugs/bug-fixes are not documented.
7) Hocus Pocus Ways
— Just keep on raising bugs as bugs and fix as many as possible in sprint, don’t care about the burndown charts and velocity. This is a practise followed at some places.
— Do Sprint Planning, work in Sprints but user story in one sprints are tested in later sprints, bugs are raised and fixed without any links to the user stories. Stories have a long long life!!
— Just do whatever suits you and call yourself AGILE proudly!
There are so many ways and tricks to do this. One approach which suits very well on one project might be a disaster for some other project. But the crux is to find something what works best with your team and your project. I would love to know what is working for your Project at the moment and why.