Time boxing effort as acceptance criteria of last resort
As a Product Owner or Developer
I want I want to understand how to deal with a lack of clear acceptance criteria
So that I don’t delay delivery
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]]
Other Blogs from this category
As a Product Owner or Developer I want I want to understand the different Agile testing methods So that I can decide which to useIn the word of Agile, there are currently three methods that can be used to improve our testing practices and to assist with enabling...
When talking about testing in a data project we have to first identify that the testing we need to do is similar but different to the testing we do in application development project. One of the useful way to identify these differences is to understand a number of the...
When do BI projects that require new data we know anecdotally that once we have acquired the required data from the System of Records the majority of our time and risk is applying code that transforms and/or augments data. In my terminology I call this "doing bad...
As a BI Manager I want to understand the impact of pipelining the Agile teams workflow So that I know if it is an approach I wish to use Managing to complete an AgileBI build in three elapsed weeks is very very difficult. And by a build I mean from...
As a Stakeholder or Product Owner
I want to understand where the traditional planning documents fit in the AgilebI process
So that I know when I need to have them created
As a BI Practitioner
I want to understand what AgileBI processes are
So that I know what processes to implement (and what processes not to)