When to accept user story

When is the best to accept 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 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 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 the 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 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 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 the approach A to the end of two-three weeks cycle.

Agile teams often do the acceptance in a sprint review session. For product owner, it is the first moment she sees the outcome of the team.

Too bad! You lost a chance of really completed 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 to clone them. A lot of waste of energy 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.

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?

1. We want to have another user story available for deploy to the production environment as soon as possible so customers can be satisfied with the fast delivery.
2. Product owner knows instantly how the plan is progressing.
3. Production guys deliver one change which is typically small (3-5 days of work). This decrease probability of defects (because of general industry statistics, 1 bug per 10 code lines).
4. The team gets feedback constantly. That motivates a lot. They know they develop something valuable which helps our users.
5. 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.

For us, this approach means regular, often, and fast collaboration. At the end of every user story at the best.

Will you consider try it out?