I need to know that does team need some kind of approval or something from product owner or scrum master when it completes a user story. And if not, then how the team proceed with this kind of situation?
-
1Hi - if you believe there's some sort of approval needed in your agile process, you might have deeper problems understanding the agile mindset. I'd strongly suggest to raise it to your Scrum Master so that he can coach you and the team about not only the approval (already answered below) but other agile aspects (such as the agile values and scrum values & pillars).– Tiago Cardoso ♦Oct 4, 2020 at 11:17
4 Answers
TL;DR: Once a story is completed, the team needs feedback on it. This can be done as stories are completed, or the team can receive feedback during the Review Meeting. The sooner, the better.
During Sprint Planning, the team decides what user stories and product backlog items to pull into the sprint. They choose on what they will be working on from the items the Product Owner considers most important (i.e. the top of the product backlog).
The stories should have a Definition of Done (for ex.: they must be developed, tested, code reviewed, etc) and the stories also have some acceptance criteria attached to them (i.e. what do you look at to see if the story actually does what's required; it might be developed, tested, code reviewed, etc, meaning that they respect the Definition of Done, but does the story do the right thing?).
Both the Definition of Done and the acceptance criteria have to be met for a story to be considered actually done (see here for the differences between Definition of Done and Acceptance Criteria).
At the end of the sprint you have a Review meeting when the team demonstrates the stories they have completed during the sprint and they can get feedback from the Product Owner and other stakeholders, but it's usually a good idea for the Product Owner to look over each story once it is completed, and not wait until the review meeting. That way, the product owner can determine if the story is done and catch any problems with the story implementation before the end of the sprint, thus still having some time for the team to make corrections.
I encourage the teams I work with to show their development work to the Product Owner throughout the sprint. This makes the need to have a Product Owner review at the end less important.
It also helps to reduce the frequency of requirement misunderstandings.
The name Product Backlog Item (PBI) is often used interchangeable with the User Story (US) but not necessarily the same. A US is one of the ways to define a PBI. A PBI has a specific set of requirements that define when it can be called done (Definition of Done (DoD)).
When you say "complete the User Story", if you're not taking into consideration DoD, then there's space for it to not be really done. I think the case is that what you mean by complete is "The developer just coded what looks to be the US"... so there's something lacking. In this particular case, it's common to move that US to a stage called "Test" or "Quality Assurance" in which the Development Team would ensure it follows the DoD before moving it to "Done".
-
-
1@jastor_007: DoD is common to all user stories (i.e. general rules for something to be considered done). Acceptance criteria are unique for each story (i.e. particular rules for a specific strory to be considered done).– BogdanOct 4, 2020 at 8:12
-
So both the DoD and acceptance criteria have to be met for a task to be done, am I right? Oct 4, 2020 at 8:17
-
-
Can you give a example of DoD and acceptance criteria? I am not sure I understood the difference between them @Bogdan Oct 4, 2020 at 8:20
The definition of done usually includes some degree of review and testing by the PO or other stakeholders. The aim is to have backlog items ready for release by the end of the sprint. At the sprint review you then seek feedback about the features you have built and that may lead to additional stories for future sprints.