If you've ever waited until the end of the sprint to demonstrate a new feature to the product owner you might have had similar feedback to me. "The address lookup is great, but isn't there a way we could autocomplete addresses from an address validation service?".
It can be a little frustrating when sprint review meetings are the moment for the real acceptance criteria to emerge. But it's the end of the sprint and we haven't got any time to incorporate any feedback, even tiny suggestions.
The story has to be accepted or rejected. Now.
We are often forced to compromise. We encourage the product owner to accept the story as-is because it meets the acceptance criteria provided at the start of the sprint. And we use the new acceptance criteria to create a new story to hopefully refine the feature later.
It was my friend, Isabel Gilad, who started arranging sneaky side sessions to present new features to Beth Cozza at Advantage Sales & Marketing. Before the end of the sprint! The features hadn't been tested or documented.
Isabel's stories were complete but weren't done. But it worked.
Beth welcomed the opportunity to see features before they were done; while she still had a chance to amend the acceptance criteria. And Isabel loved the opportunity to deliver a better feature by the end of the sprint.
Isabel called them NFF: new feature feedback sessions. I call them story previews.
Five story preview best practices for CRM projects
Here are some tips for getting the most out of your story preview sessions:
- Make sure your product owner, or their delegate, is going to be available for some mid-sprint story preview sessions. Ideally, schedule your story preview times during the sprint planning meeting. Have an idea of which stories should be demonstrable at each preview.
- If you know your feature is going to be previewed, don't finish the feature testing or documentation until after the preview.
- Bring another team member with you to the story preview. Ideally, bring the person who is going to test and document the feature before the end of the sprint.
- Agree on any new acceptance criteria and add them to the story and let the team know before or during the next daily standup.
- In the story preview, don't commit to incorporating all feedback during the current sprint. Tiny changes might be OK, but there are often unintended consequences of small changes that you miss and other team members might notice.
What if feedback changes the story's estimate?
If you are the team member that owns the story then you should be able to make the call whether you can incorporate the feedback into the story within the current estimate. But other team members will also have tasks related to your story too. If the preview feedback causes you to take longer to develop the feature, it's not fair to squeeze the time for their tasks.
If your sprint has a little slack that will allow you to deliver a better feature within or very close to the original estimate then go ahead. But if the feedback added a couple of new acceptance criteria and you think the 5-point story now looks more like an 8-point story then you'll need to add a new story to the backlog.
Whether you can incorporate the feedback within the current story estimate or you decide to create a new story to refine the feature later, make the decision as a team. Involve the Product Owner, Agile Coach and your other CRM team members so that everyone is on board.
Have you had success with story previews? I'd love you get your feedback about getting feedback in the comments.