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!
Pros??
— 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.
Challenges??
— 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.
Cons??
— 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.
Cons??
— 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.
Pros??
— 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.
Cons??
— Ideally, one can not add a user story to Sprint backlog within a sprint. So, this seems like an outright wrong approach.
Challenges??
— 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.
Pros??
— 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.
Challenges??
— 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.
Pingback: 4 Helpful Agile Articles - Neotys Testing Roundup
Pingback: Testing Bits – 11/3/13 – 11/9/13 | Testing Curator Blog
Tom Grant said:
If you invalidated every story because of a known bug, you’d make very little progress. Certainly there are bugs that make it impossible to say that the code is working, but there are trivial bugs, too.
I think it’s a bad idea to turn bugs into stories. Stories should describe how you add value to the system, and bugs don’t add any value. In some circumstances, however, “bugs” are really missing behavior that does actually add value. That’s about the only time I’d consider turning a bug into a story.
LikeLike
rumadak said:
Thanks for your input Tom!
Agree with you that bugs should not qualify to be a user story!
LikeLike
Trish McIlwraith said:
How can a story be marked Done if there are unresolved identified bugs associated to it? I believe that bugs found during system testing should be added as tasks under the Story being tested. This allows the current Story to remain in testing whilst the bug issue has a life of its own.
For issues found that are not related to any of the Sprint stories or are related to a signed -off story, they should be added to Project backlog and kept out of the Sprint.
LikeLike
rumadak said:
Trish,
Thanks for taking out the time to read the post and commenting 🙂
I agree that a story can not be marked as done if there are open BUGS related to the acceptance criteria of the story. For all the ways in the post, I meant to keep the story in ‘In Progress’ lane of the Wall.
LikeLike
Manish Chhabra said:
My 2 cents aka my beliefs
1. If the bug is found while QAing a story “X” and the bug is related to story “X”. The story should be reopened. (Point 2 from your post)
2. If the story “X” has been QAed and accepted and later a bug is found related to that story then a separate bug should be recorded (Point 1 from your post).
3. A bug is not a user story (unless it is change of requirements).
4. I really like the term Hocus Pocus Ways but would not be happy with that in a project.
LikeLike
rumadak said:
Thanks Manish!
I like the way you have differentiated between # 1 and #2!
About Hocus Pocus Ways: Thanks for liking the term!! True they don’t reflect AGILE is many ways but still in practise!
LikeLike
tcagley said:
Great post. I am a believer in either #1 or #2 and have implemented bug tracking on card walls. What is your favorite approach?
LikeLike
rumadak said:
Thanks Thomas!!
I like #1 , #2 or #4
LikeLike