The way I see it, a user story goes through different phases of understanding and its scope is refined in each of these phases. First, it starts as an idea of something that can contribute value to the application in mind. At this moment, everybody is living in the world of ideas and that world doesn't have any restrictions or constraints. The scope of this user story is completely blurred.
When the story is estimated for the first time, it transitions to the second phase. Developers go through it for the first time, providing hints on the feasibility of the user story (or what would need to be changed in order to be feasible). QAs also help refine the story because of their ability to think of the different scenarios this user story could apply to. This is the first time (usually) the team (or at least a representative part of it) look at the user story and discuss about it. The user story takes shape. Acceptance criteria are usually added (based on the questions and discussions that arise) and the scope is radically refined to a point where the team should understand at least what needs to be done.
The planning meeting represents the third phase of refinement for the user story. At this point, the product owner explains the user story to the whole team. This should be the last phase because a scope is agreed on and a final estimation, to which the team commits to, is made based on it. But is it?
When the user story begins to roll and QAs start thinking about scenarios and test cases, developers start designing and something starts to emerge, the understanding of the user story changes a great deal. Even more, seeing something concrete triggers new ideas or unveils constraints that were overlooked. Continuous communication and collaboration between the team and the product owner is vital to overcome problems and accommodate all necessary changes. Finally, the user story is completed and with it, the user story transitions to its last phase.
All of these phases happen usually in a very short period of time in most agile projects. There isn't a big upfront analysis and design period and the project start with just the vision and a bunch of user stories understood. The rest is decided on the road. Even more, in many cases, the requirements will change and a successful agile team should be prepared to handle this. The key to be successful in this environment is to have a gelled team with a lot of criteria.
So what happens when after the user story is completed, some part of the functionality doesn't meet the expectations of the product owner or some of the stakeholders. The question: is a bug or a feature always arises. The easy answer is: if it's not among the acceptance criteria listed, is a feature request. I don't think it should be that easy. I believe the team should use its best criteria to determine if the issue is far enough of the core of the user story to be considered a new feature request. I believe Agile relies on a bunch of crafted people that add value during the whole life of the user story and I believe that a shared framework of understanding should exist between the product owner and the rest of the team (this is key for the success of the project). In other words, a successful team understands what is being expected of the product, which is the criticality of it and what is the level of necessary quality. Having all of these things in mind, the team can make a decision and my opinion is that if the issue belongs to the core of the user story, it is just healthier for the group to recognize it was missed and track it as a bug.
Changing the perspective, perhaps it doesn't even make sense to make this distinction. A new level of understanding has been reached for the user story and what is important is to decide if the missing functionality is required for the next release or not. This makes the decision even easier. One of the reasons the team has to categorize something as a bug is that if it’s a bug, it will probably need to be addressed for the release and so it implies more work. If it is a new feature request, it will probably go to the next release. If the product owner, who is the person responsible for the ROI of the project, decides this need to be included, the decision falls to how it is going to be tracked.
In conclusion, a successful scrum team should first ask the product owner if s/he thinks the functionality missing is important for the release and then track and prioritize the work that needs to be done. A team should be fond of their work and their craft and it should use its best criteria to make the decision. And finally, if it is a new requirement, it needs to be prepared to change. We live in a very competitive world where business conditions change all the time. The success of the team depends on being able to accommodate those changes.
The success of the team relies on being really Agile.
Perhaps could be a good idea, sometimes separate the responsibilities for Validation and Verification. While VER is responsible for "verification of the product and intermediate work products against all selected requirements", VAL is responsible for demonstrates that the product, as provided, will fulfill its intended use; whereas, VER addresses whether the work product properly reflects the specified requirements. In other words, VER ensures that “you built it right”; whereas, VAL ensures that “you built the right thing.”
ReplyDeleteThen VAL can decide if the if the bug is a bug or is a feature request.
Another aspect to keep in mind is the experience of the team using AGILE. Isn't easy for a Q member, add a new switch to analyze if an issue is a bug or a incomplete feature, the same happens with any team member without an experience in agile.
Nice post. I agree with your thoughts "it doesn't even make sense to make this distinction." and the important is the learning process. However that's not always true for the team members. To them the distinction is sometimes important, emotionally speaking. So a basic agreement on how features vs defects will be categorized and who will take the final decision on it, could be useful for teams which are starting.
ReplyDeleteBy slicing the user story into vertical slices such that the first slice is a single "happy path" scenario, and each subsequent slice adds more scenarios including handling various errors and unexpected situations, then the discovery and refinement happens during the feedback to slice N and the final definition of slice N+1.
ReplyDeleteThen bugs will only be when the current slice does not actually handle the agreed upon scenario, not when testers or customers discover some situation that was not covered.
I think the distinction between 'bug' vs 'feature' is not particularly important during the course of an agile project. Both represent 'undone work', and it is up to the Product Owner to decide the priority for each to be done. Furthermore, in both cases, tests need to be defined to automatically tell us when they are done.
ReplyDeleteI prefer to use the term 'anomaly' when a (potential) bug is first noticed or reported. At that point it is simply a difference in actual versus expected behaviour, but the expectation itself could be wrong. Thus, a reported anomaly or bug is just an opinion, until the PO agrees that the system behaviour needs to change in an explicitly defined (hence testable) way.
Usually the arguments over 'bug' vs 'new feature' are caused by team members being measured on unhelpful metrics.