A proper development iteration will involve the development team working on a user story, and towards the end of it, showcasing what the team has completed. This is not only critical to get feedback from the product owner, but also from a scope management standpoint, which most teams tend to neglect.
It is the responsibility of a Product Owner to sign-off on a User Story narrative before the beginning of the iteration, and see the working software during the showcase. Sometimes Product Owners do not end up doing this because of various reasons, and this can result in the following smells
Story requirements keep changing constantly within an Iteration
A narrative signoff is an agreement between the Product Owner and the Development team around the Acceptance Criteria of the story mentioned in the narrative. Sometimes Product Owners shy away from doing the same because they are not sure what they exactly want in the given story. They also want to work in a mode where they can propose changes to the same story within an iteration, since in their mind, as the team is doing agile , it is supposed to embrace changes at any point in time.
This setup results in story changes leaking into a development iteration and causing a lot of churn, and hence wait in the form of code and testing effort. This also results in a team not achieving sustainable pace with every iteration, because of constant changes in user stories,
A fix to this problem,is to coach the product owner on writing/signing-off User Story narratives well before the Iteration starts. What is also required is to make him/her understand that a change made later in the iteration will come at extra cost. One also needs to highlight the amount of waste generated because of changes being made, and the hidden costs associated with thrown away code etc...The team should ideally work in a mode, where if a story narrative is not signed off within an iteration, it should not be played at all. And once development has kicked off for the story, any change to it, should come in as additional scope request which is up for negotiation.
Stories do not get accepted at the end of an Iteration, and the team does not have a clear definition of "Done" for stories.
If Iterations are planned correctly then towards the end of every iteration, stories developed in that time frame should be showcased to the Product Owner and accepted. Sometimes Product Owners are averse to the idea of "Acceptance of a User Story" and insist on a feature being complete to sign-off. Taking such a stand results in many stories within a release pending acceptance till the very end of a feature. Some Product Owners lean towards this claiming a complete feature is much more testable and makes logical sense than a single user story. If this is happening, then it is either a case of your User Stories not following the INVEST principle or the product owner wanting to delay commitment for various reasons.
Again this very problem should be fixed as early as possible in a project. The practice of acceptance of stories every iteration ensures that the product owner has validated the working software as per his spec every iteration. The feedback cycle is cut short and any change beyond this point on requirement is a new story altogether. More importantly, this builds a lot more confidence in the development team that they are on the right path. Ideally, "Customer Accepted" should be the definition of "Done" of a User story, and only when a story is "Customer Accepted" should it be counted in velocity of the team,
The Product Owner role is critical for an Agile team to work smoothly. A good product owner should not only have an excellent view of the product and domain, but also understand the importance of some of his responsibilities towards the delivery team.
It is the responsibility of a Product Owner to sign-off on a User Story narrative before the beginning of the iteration, and see the working software during the showcase. Sometimes Product Owners do not end up doing this because of various reasons, and this can result in the following smells
Story requirements keep changing constantly within an Iteration
A narrative signoff is an agreement between the Product Owner and the Development team around the Acceptance Criteria of the story mentioned in the narrative. Sometimes Product Owners shy away from doing the same because they are not sure what they exactly want in the given story. They also want to work in a mode where they can propose changes to the same story within an iteration, since in their mind, as the team is doing agile , it is supposed to embrace changes at any point in time.
This setup results in story changes leaking into a development iteration and causing a lot of churn, and hence wait in the form of code and testing effort. This also results in a team not achieving sustainable pace with every iteration, because of constant changes in user stories,
A fix to this problem,is to coach the product owner on writing/signing-off User Story narratives well before the Iteration starts. What is also required is to make him/her understand that a change made later in the iteration will come at extra cost. One also needs to highlight the amount of waste generated because of changes being made, and the hidden costs associated with thrown away code etc...The team should ideally work in a mode, where if a story narrative is not signed off within an iteration, it should not be played at all. And once development has kicked off for the story, any change to it, should come in as additional scope request which is up for negotiation.
Stories do not get accepted at the end of an Iteration, and the team does not have a clear definition of "Done" for stories.
If Iterations are planned correctly then towards the end of every iteration, stories developed in that time frame should be showcased to the Product Owner and accepted. Sometimes Product Owners are averse to the idea of "Acceptance of a User Story" and insist on a feature being complete to sign-off. Taking such a stand results in many stories within a release pending acceptance till the very end of a feature. Some Product Owners lean towards this claiming a complete feature is much more testable and makes logical sense than a single user story. If this is happening, then it is either a case of your User Stories not following the INVEST principle or the product owner wanting to delay commitment for various reasons.
Again this very problem should be fixed as early as possible in a project. The practice of acceptance of stories every iteration ensures that the product owner has validated the working software as per his spec every iteration. The feedback cycle is cut short and any change beyond this point on requirement is a new story altogether. More importantly, this builds a lot more confidence in the development team that they are on the right path. Ideally, "Customer Accepted" should be the definition of "Done" of a User story, and only when a story is "Customer Accepted" should it be counted in velocity of the team,
The Product Owner role is critical for an Agile team to work smoothly. A good product owner should not only have an excellent view of the product and domain, but also understand the importance of some of his responsibilities towards the delivery team.