When is the best to accept the user story which is finished and who should accept them?
In our Agile and Scrum Fundamentals training, people are (surprisingly) surprised when we present our approach of the acceptance of finished work. At the begging we often observe disagreements, but after a few minutes of an explanation why we found our way valuable, the mindset of participants is slowly changing. Well, for most of the people.
So let’s summarize alternative approaches to how the acceptance is done in real life by agile teams…
When to accept user story – A. Acceptance sprint
New agile teams often do acceptance at the end of the project. Yes, it sounds anti-agile and it is in fact anti-agile.
But there are real people who deliver projects to non-agile customers who ask (hard) to have some User Acceptance Test phases. Of course, the problem is they ‘don’t get Agile‘, but the question still remains. Why should they do that if it is not important for them?
So agile vendors take the easiest path. Let’s have the acceptance sprint. Typically at the end of the project or program increment. Which is toooooo late, toooooo bad.
In such a situation, your aim as an agile vendor should be to build up the capability of continuous delivery. Prepare your product to the stocks, let the customer pull another portion from the production when necessary. Invite them at least to the pre-production stage. They are afraid of the production stage breakage, but they do not hesitate to test the results more often.
And if they do, you know it will be hard anyway. In reality, they do not want the real product so be prepared for that.
When to accept user story – B. Acceptance user story
With this approach, the last card in the planned sprint backlog is the Acceptance index card.
Sounds better? It is not! You just postponed approach A to the end of two-three weeks cycle.
Agile teams often do the acceptance in a sprint review session. For the product owner, it is the first moment she sees the outcome of the team.
Too bad! You lost a chance of really completing work. The team will not have a feeling of finishing. The work feels like a heap of sand. Growing and growing. These teams discuss a lot if they should split user stories, or move them to the next sprint, or clone them. A lot of waste of energy is better to put into the development itself.
When to accept user story – C. Acceptance subtasks
This is our preferred approach in building up ScrumDesk, our scrum online project management tool. Every user story must have the acceptance subtask assigned to the Product owner.
We even have a rule that acceptance subtask must be moved to Done column in 24 hours from the moment when the last task has been completed. This help us be ready for the production as early as possible. To be ready for continuous delivery.
As Product Owner, I can find easily user stories for the acceptance as their ToDo column is empty except Acceptance subtask card. We even use a special (white) color so the task is even easier to find.
Why 24 hours limit?
- We want to have another user story available for deployment to the production environment as soon as possible so customers can be satisfied with the fast delivery.
- The product owner knows instantly how the plan is progressing.
- Production guys deliver one change which is typically small (3-5 days of work). This decreases the probability of defects (because of general industry statistics, 1 bug per 10 code lines).
- The team gets feedback constantly. What motivates them a lot. They know they develop something valuable which helps our users.
- We can rearrange priorities easier as the development is done by an order of cards in the backlog. It is so easy for the product owner to react to changes.
As a Product Owner talking to the team it might be so easy to say “I didn’t have time for the acceptance.” But this is just an excuse.
With 24 hours the Product Owner is limited. Should I miss this acceptance time window, anything I did not accept is accepted automatically by the team? And then it is me who faces the customers.
The sprint backlog is our common aim. The team and the product owner want to satisfy the customers with the right things done right as soon as possible.
For us, this approach means regular, frequent, and fast collaboration. At the end of every user story at the best.
Will you consider trying it out?
