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.
