Acceptance criteria for a user story is crucial.  Without it the development team and product owner are unable to agree when they have done enough effort to be classed as Done Done.

Without acceptance criteria the development team will more than likely go down some rabbit holes wasting effort on solving problems the product owner does not see as a priority or over engineering a solution.  All resulting in not meeting the vision and expectation for the sprint iteration.

Without acceptance criteria the product owner can change what needs to be done without discussing the impact of this change with the development team.

Neither of these are good practices within the AgileBI approach.

But setting acceptance criteria is hard, it is especially hard for user stories where nobody has done this work before.

That’s one of the reasons we have adopted Ralph Hughes concept of Basis of Estimates [[ref]] so that the team can fast track the estimation of the things they know, so they can spend their valuable time estimating the unknown.

So when we hit a user story where we believe we would spend more time debating the acceptance criteria than actually delivering the story we fall back to time boxing.   This is a simple acceptance criteria, spend 4 hours (or any time you ascertain as acceptable) working on the user story and then stop.

It is unlikely you will achieve the value the product owner is looking for, as they are unable to articulate the acceptance criteria for this outcome.  But at a minimum you will end up know what you don’t know.  And when you create a new user story in the next sprint iteration for this outcome, it is highly likely you will be able to agree to valid acceptance criteria as you all know more.

We only use time boxing as a last resort:

• It is a result of the product owner not being able to articulate how they will measure if you have delivered what they want, it means they are not clear on what they want
• The product owner may start to default to time boxing acceptance criteria for all user stories as it is easier
• The developers cannot break the user story down into developer stories, so they will be unclear of the steps they need to take to deliver it in the sprint iteration
• Some of the developers in the team will be more comfortable working on these research style stories, but they might not be the members that are available to pull the story from the backlog
• The members of the team who love doing these style of user stories and may not pull other stories from the backlog that have proper acceptance criteria
• Presentation of the delivered value for this user story at demo day is likely to be weak

We often classify these user stories as “research stories”.  This enables us to easily identify these stories compared to user stories with suitable acceptance criteria.

&&link to research stories&&

[[what is a research user story]][[reserach stories acceptance criteria]]

Some other options we often use for acceptance criteria are:

• Setting the number of maximum pages for a document, so the level of detail in the document meets the expectation.   This stops the development team writing a 50 page document for most of the sprint iteration when the product owner was just expecting a short overview document.
• [[fidn some more]]