Demos as acceptance criteria
So I've just started a new job, and am serving as both the dev manager and the scrum master (I know, I know, let's save that for another thread...).
The PO has a habit of putting in the acceptance criteria things like this:
* "Demo to product"
* "Demo to product/Tier3"
* "Demo to product/Tier3/security"
* "Demo to product/Tier3/securityUX"
Tier3 means someone the support team, "UX" means someone from the user experience/user interface team, and security is someone from the security team.
So here's my question: Am I nuts in thinking anything beyond "Demo to prod" is not agile, not sane, not sustainable, not cool? Obviously prod needs to see the story. But having to invite any or all of those people to a demo of a SINGLE STORY to meet acceptance seems ludicrous, and I feel like a cad sending the invitation.
I've reached out to people here (the teams mentioned) and gotten mixed feedback. But if you ask me, having demos (to anyone other than prod) as part of acceptance criteria seems whack.
Just looking for some feedback.
Thanks,
D
The demo is to the Product Owner. That's it.
It's up to the Product Owner to decide whether that is going to be acceptable to all the other stakeholders.
That said, I would encourage all the stakeholders (support, ux, sales, whoever) to see the demo to give their feedback, but it is the PO who accepts or not accepts the stories (based on the acceptance criteria that is mostly defined at sprint planning). That feedback can be very valuable (and the PO may not be great at gathering all that feedback).
It's the PO responsibility to make sure all those people are satisfied, not the team. The others could all attend (and I would argue should), and give feedback that requires changes, but those would be new stories if the PO didn't capture them properly. The acceptance of the stories should only be based on the acceptance criteria.
Acceptance criteria of "demo to X" are totally useless. You can meet that criteria by demoing the functionality *whether it works or not*. Your PO is trying to avoid his/her responsibility of deciding whether the product is functioning properly by saying all his/her stakeholders are ok with it. That's going to cause major problems in the acceptance of stories. The PO needs to take the responsibility of taking the divergent opinions and having stories with acceptance criteria that will satisfy all the stakeholders (or if they are not satisfied at least they understand why that decision was taken).
You are not nuts, having multiple people having to accept the functionality is a major problem, and is exactly why you have a PO in the first place.
Those aren't valid acceptance criteria, because they include things that are outside of the Development Team's control. They are not in a position to obtain approval of work items from anyone outside of the Scrum Team. They can only obtain, and should only ever need, the approval of the Product Owner.
The Product Owner has a right to seek the advice of people outside of the Scrum Team. The PO also has a right to invite stakeholders of his choice to the Sprint Review. However, the PO does not have a right to delegate the responsibility for liaising with such stakeholders to the Scrum Master or Development Team.
A Scrum Master should coach the Development Team not to accept user stories, acceptance criteria, or a Definition of Done which has dependencies that are not under their control. If necessary, an SM should also be prepared to coach the Product Owner regarding his or her duties and responsibilities.