Agile, Basic Scrum

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!