Ready For Sprint?

Ready for Sprint?

Have you ever been sitting in a sprint planning and heard the following sentences:

  • “Can we split this user story and at least start with the GUI?”
  • “I’m not sure if the hardware will be available on time to integrate this story but we could use an emulator instead.”
  • “There are no wire frames yet, but we could start with the back-end.”
  • “The acceptance criteria are still quite vague, but I think I know what the customer needs.”
  • etc.

Does some of these sentences sound familiar? I observed these conversations several times in the past. All of these quotes are based on the same problem: The user story is simply not ready for the next sprint. Still, some teams pull these user stories into there next sprint to implement at least a part of it, to make the PO happy. Stop it! It doesn’t make sense at all. None of these user stories will be done at the end of the sprint, because important parts are missing. These teams have to be reminded that every user story has to be implemented, tested, integrated, documented and shall deliver value to the end user. If you already know at the start of a new sprint, that you won’t be able to finalize a user story: ditch it!

But what can you do to avoid these discussions? There is a simple solution: Introduce the “Definition of Ready” (DoR)! The DoR defines, when a user story is ready for a sprint. If it doesn’t comply with this definition it will be ignored in the next sprint planning. As the “Definition of Done”, the DoR is defined by the team itself and therefore varies from team to team. If you’re e.g. developing a web application, hardware may be not that important for your team, but if you’re developing software for e.g. a medical device it is could be important. Sit together with your team and your PO and define what the DoR has to contain in your current situation. Agree, only to pull those stories into your sprint, that are ready for sprint.

Most agile teams I know implement a DoD, but the DoR is still only rarely used. I hope this will change in the future. Don’t waste your time implementing half-baked user stories. You can use your time better than that.

What are your experiences? Leave a comment!

6 thoughts on “Ready For Sprint?”

  1. Unfortunately I observed this behaviour too – even if they have a definition of ready. It goes like: “Yeah, we know – we have the DoR and if we would look at this we can not start the programming. But we don’t have the time to wait for a fullfilled DoR, we must start now otherwise we would have nothing to do or will break the given timeframe…”

    I think this comes from the old thinking/idea to make the customer (or the PO) happy with starting soon and doing something. But this will not make the customer happy, because with this way the customer won’t get the best for the money. They get something that needs to be changed afterwards and someone has to pay for it.

    What can we do beside letting everyone know the risk that they have to deal with? (As I said – we already have a defined DoR)

    1. If you have a DoR and don’t adhere to it is worthless. My first question would be: Who created the DoR? If everybody (team, SM and PO) were involved and everybody agreed on it, the team has to skip stories that are not “Ready”. The SM should coach the PO during a sprint on getting stories ready. It is in the PO’s responsibility to plan ahead, otherwise he won’t get anything. If you have a DoR and don’t adapt accordingly, nothing will change.

  2. Change of mindset and a deeper understanding on what and why has to take place – that needs time and coaching. (DoR was created by the team and given to the PO. He agreed on it…)

  3. I need to partially disagree. If a story can be split up into two or more stories and at least one story is meets a DoR, there is no issue. Proceed with the story that is ready!

    Problems occur when, as you point out, a story is simply not ready and the team decides to “do the best they can”. This will inevitably involve some guess work. The wrong guesses will come back to haunt the team and likely result in technical debt.

  4. Agree with Vin. If you can split the story into relevant bits, then go ahead. I’ll add something I’ve experienced. The DoR can encourage devs to reject too many stories because they don’t meet requirements. That’s what materializing borders can lead to. You have to be careful not to replace discussion/negociation with process and rules. Apart from that, I totally agree that having a checklist everyone agrees on definitely helps. Whether it’s needed/helpful or not, depends on the relationship between devs/PO/QA.

Leave a Reply

Your email address will not be published. Required fields are marked *


Notify me of followup comments via e-mail. You can also subscribe without commenting.