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.
Hi Anand, would there be the anxiety of sign off on stories, i.e. would the PO look to sqeeze more into a story because the sign off may be seen as concrete? This is something I have experienced in the past. Also, do you think that the granularity level of a story may help to reduce the pressure of additional changes to a story mid iteration? Cheers D.
ReplyDeleteHi Anand,
ReplyDeleteGood post. I wrote a similar post on the impact of unknown on estimation of Agile projects.
"http://nileshgule.blogspot.com/2010/01/impact-of-unknowns-on-agile-project.html"
How are thing at your end right now?
Hi Anonymous,
ReplyDeleteYes, I have experienced the anxiety as well. But what a PO should be made to understand is the team has not estimated for a change which is happening in the middle of the iteration. The team is not saying no to it, but just play it later after a proper estimation and slotting in the plan.
Again regarding granularity, the acceptance criteria of a story should be in a simple format which clearly identifies if this story is completed what will the user be able to do.
It should be unambiguous.
Thanks,
Anand
Hi Nilesh,
ReplyDeleteNice post and I can quite understand the context behind this as well ;-) . Again how the Product Owner works and the steps he/she takes to understand the delivery team is critical for the team's success.
I am doing fine at my end.. Great to see you blogging !
Thanks,
Anand
Not sure if I completely agree with the notion of a 'sign-off'...it reeks of a contractual relationship...which probably is a reality in most cases. But then that was the premise of the traditional approaches to S/W development that an Agile approach was supposed to better:)...the only difference seems to be instead of getting into a battle with the PO/Business/Customer at the end of a 6 or 9 month dev phase, have little fights every iteration:). I am only wondering if the Kanban 'consume as you purge' combined with a non-adversial relationshop with PO would be better.
ReplyDeleteVishy,
ReplyDeleteYour comment actually brings up another interesting point, that the style of Agile we follow while developing a product inhouse v/s while developing for an external client varies. It becomes more contractual when the PO is an external client. I also see this difference in perspective in agile community discussions often.
IMO the less contractual, light weight planning model is probably the best way to go, but that would need a lot more trust and coaching the client in a services world.
Agree Anand, ghar ki murgi daal barabar (home made chicken=lentil soup:)...my only contention is that the behavior of seeking 'sign-offs' moves us more towards a contractual than a collaborative relationship.
ReplyDeleteMaybe its just NLP:) and words we use,
sign-off= contractual
We (PO and Dev) agree=Collaborative
I feel that, Instead of good product, quality product is very important. I think that, customer satisfies in cheap and quality products. Story is very nice.
ReplyDelete