This is a question I received from Etienne in part 2.
"But when there's a problem with the behavior of a New Feature, how do you call that?"
It depends. When talking about a new feature, my guess is that you are talking about a feature that has yet to have been released.
In that case, even when using the bug type in a backlog, I would never raise a bug on a feature that has yet to have been released. The feature is not delivered, thus the bug is simply remaining work that has yet to have been addressed in order to be able to deliver the feature.
In that case, I would either add the details of the strange behavior in one of the existing tasks or create a new task to the story related to this behavior.
One strange thing that I have seen being done was team members raising a bug mid-sprint to be fixed later in the sprint or in another sprint(!) for a feature that got broke by the development of a new feature.
Why people would do this is beyond me. This is allowing the software to regress on purpose !
I would rather follow the Primum non nocere(first do no harm) maxim that is used in medicine.
Ideally, introducing a new feature should never make the software regress. At least not on purpose. Of course, there will always be times unwanted behavior is introduced without us knowing.
As always, having a fully automated test suite goes a long way in making it much easier for a team to discover the regression they are introducing as they go along and to make adjustments along the path.
I'll be back soon with more feedback on how we are using our bug free backlog within team Sosoft.
Feel free to give us your feedback on our approach. Maybe we're just a bunch of loonies after all :)
-Nicholas Lemay.
2 comments:
I absolutely agree with you that bugs created and found in mid-sprint should be fixed rigth away. There's no point in introducing faulty behavior, even though I've seen that happen quite often.
My question was more along the lines of how do you call faulty behavior in a new feature found after the end of an iteration. If you introduce a bug and have a failing acceptance test, then I guess you should just fix it. But in some cases, maybe there's just been some misunderstanding and the bug is found by the client while doing his acceptance testing, in the case of in-house or outsourced software development. If you have a commercial or opensource product, the bug could be found by a end-user.
I guess you'll answer these questions in your next post ;)
Sure will :)
Thank you very much for you feedback and questions. Very appreciated.
Post a Comment