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.

Read the rest of this blog post on

7 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.