Are You Ready? How to Make Sure Your User Story is Ready Every Time

In my last blog post, I did something out of character by writing about Taylor Swift and Software Development.

This time, I am going to reference something a little closer to my own music tastes.

As AC/DC asks – “Are You Ready”?

Besides being more inline with my rock music tastes, this question has been on my mind as I have been looking at results from our most recent internal SCRUM survey.

Our internal SCRUM survey is one of the resources we use to look at our SCRUM practices and rollout internally. Besides getting an NPS score on the overall process, we get a change to look at the success of our teams, practices, roles cut by role, team and technology.

This feedback is critical to monitoring what is working, what isn’t working, and what needs to be improved to help the teams adopt and run SCRUM more efficiently.

Looking at our most recent metrics and survey results, I could see two patterns that pointed to ready state as a problem. The first was a series of comments in the surveys that stories weren’t getting done because we had to “wait for UX”. The second was that there was an increasing number of stories that were falling out of sprints.

In doing some digging, I discovered the cause of the problems stemmed from many stories not being “Ready” before going into the sprint.

You can find a definition of ready from the Scrum Alliance here.

In order for a user story to be seen as ready, the SCRUM alliance suggests these three questions need to be answered:

• Why — Is it well understood what the stakeholders or business is trying to achieve?
• What — Is it well understood what the goal and outcome needs to be?
• How — Is the strategy to implement the user story understood? Is the story small enough?

This led to us drafting our own guidelines for stories:

• It is defined and written clearly in a format that identifies the User Type, Function and Benefit.  For example, a format like “As a <user type>, I want to <function> so that <benefit>.”
• As much as possible, it is self-contained, in a way that there is no inherent dependency on another user story
• It has been estimated by the scrum team
• It is small enough to be delivered within a single sprint
• It has defined and clear acceptance criteria for functional requirements
• Where appropriate, it has defined and clear acceptance criteria for non-functional requirements including performance, scalability, as well as adherence to relevant Constant Contact security and architectural standards
• Any blocking dependencies from outside of your scrum team are resolved before the start of the sprint including those generated by the UX, development, and operational teams at large.
• The team has the required skill sets available to deliver it

But these guidelines don’t seem to have helped the teams get to where they need to be. There are a number of challenges:

1. We have teams that are taking stories into a sprint that aren’t properly groomed. Yes, grooming takes some up front work. You’ll need to answer questions like:
   • Is there shared understanding of the work required?
   • Is there a shared understanding of the approach that is going to be used to deliver the story?
   • Do we understand the code design patterns and technology we are going to use?
   • Do we know the code base that is going to be worked in and know what if any other tech- debt areas may need to be touched?
   • Have all the questions, answers and decisions been discussed and understood by the team and documented in the story when necessary?
2. Has the team discussed the User Experience enough for the team to understand what needs to be done?
   1. Do we have the flow understood?
   2. Do we have the errors cases understood?
   3. Do we have the corner cases understood?
   4. Do we have any data overflow cases handled?

Most of the failures for our teams to have stories ready are actually failures within the team collaboration and practices. There aren’t good reasons why we aren’t getting stories properly ready before putting them into sprints, but we don’t seem to have those mechanics down yet.

Also, it should be clear that we aren’t expecting that everything about the story has to be understood. The interface design doesn’t need to be 100% final; the team simply needs to have enough understanding of the design to make a reasonable estimate. The goal is to minimize surprises. The UX designer can collaborate with the rest of the team during the sprint to iron out any specific details.

Same is true for the architects, we don’t need to have a functional design spec, we just need enough for the team to really understand how the code paths are going to work, what the complexities are, and what code and tests need to be written. The architect is available to the team to iron out details during the sprint.

So what are we doing about it?

We are considering putting a specific step into our grooming process, which is having the team vote to have stories be tagged as ready. We are using JIRA to create a Tag that turns a story “green” and defines it to be ready. That tag can only be applied when the team votes together that the story is ready. Then only tagged stories can be considered for a sprint.

This explicit vote should provide enough consideration and occasion for the teams to make sure that all stories are truly “READY”. The team will need to groom often enough to have enough stories for 1-2 sprints ready at all times. The success metrics we will be looking at will be how long stories at the top of the backlog stay in a non-ready state and how many stories fall out of a sprint.

Paying attention to the readiness of stories should help our teams be more successful with their sprints and consider more carefully what they need to have in order to have a story be ready.

With these changes we hope to have a solid answer to our AC/DC question

Are we Ready?

Yes, we are ready for a good sprint!

Are there other things that you have seen help SCRUM/Agile organizations? Use the comment section below to leave your ideas.

Are you an engineer or engineering leader who is looking to work and learn in an Agile culture that works on leading edge technology and is focused on delivering customer value for our small business customers? Check us out at jobs.constantcontact.com.