Wednesday, October 1, 2008

Ready-ready: the Definition of Ready for User Stories going into sprint planning

You all know what “Definition of Done” means. Just for the hell of it I’ll recap it anyway; What it refers to is a state of a chunk of work. The state is also referred to as “Done-Done”. The purpose of the Done-Done mechanism in Scrum is to ensure that those things completed in the sprints really are completed in a commonly acceptable, controlled, premeditated and agreed sense. For example, nothing should be considered “completed” until it is e.g. tested, reviewed, committed and merged – e.g. “Releasable”. Without the definition of done we risk building up a mountain of stuff that we push ahead of us, which eventually (e.g. release-day) will kill us – or at least give us a hell of a fight. What’s even worse, without the definition of done we not only build up such a mountain of stuff, we also have no way of knowing how big that mountain is until we start getting our hands dirty and digging in. And what’s even worse is that many of the things inside that mountain will take so much longer to do later than if performed immediately day 0, because the longer it waits the harder it becomes to fix, to understand, to find, to remember, etc.

So, I think we’re all in agreement that we need a definition of done for the work we ship out of a sprint. Now I think we need a similar mechanism for the work taken in to the sprint. A mechanism which ensures that the stories taken in is really ready to be taken in. Let’s call this state “Ready-Ready”.

First of all, what does “taking in” mean? Well, it means “available and up for discussion on the sprint planning meeting”. So the definition of ready needs to describe a state of stories which they must be in, in order for them to be eligible for discussion on the sprint planning. Before they have reached the Ready-Ready state the stories do not exist and will not be considered for sprint planning. I.e. the top part of the product backlog has to contain only stories which are ready-ready.

Why? To save time of course: to spare the team tedious discussions about stuff that isn’t sufficiently thought-through. To let the team focus their valuable time and energy on things that are as “safe” as possible.

So, the definition of Ready should be;
  • A user story exists which points out the actor, describes the targeted feature and the purpose of it. The story should be formulated like this; As a I want to because . The first two are often easy to pinpoint but the purpose is often overlooked, because it feels obvious. But is it? The idea with writing down the purpose is to give the reader a good feel for the context of the feature – what problem it solves. Not only what it is but also why. This way, the reader can form his own opinion on how to implement it. It gives the reader a deeper understanding for the story.
  • The formulation of the user story is general enough for the team to have the flexibility of delivering it in increments. Don’t describe every detail. Describe roughly what you want but leave the rest for discussion.
  • The story is small enough to fit inside a sprint. Stories larger than that need to be broken down. Breaking down and reformulating stories have to be done before the sprint planning. Obviously, a story cannot be completed in a sprint if it is larger than a sprint. So care should be taken to ensure they are small enough.
  • Each story has its own unique priority in relation to every other story in the product backlog. This is to ensure that the team can work on the most important things first, and to force the product owner to make intelligent decisions about the order of stories.
  • The story has a description of how it can be tested (demoed). The description need to give the reader a good sense of what determines if the story is completed or not. It should be e.g. the acceptance test that is described here. It can be used as a description of how to demo the story too.
  • The story has been estimated (in story points). This should preferably be done by the whole or parts of the team, but at the very least it should be done by individuals with the same understanding of the system and the domain as the team who will eventually be working on it.
So in our case we should have meetings prior to the sprint planning meeting, where the product owner meets the teams and sits down and discuss the product backlog. Don’t forget to time-box the meeting. The goal of the meeting is to deem stories as ready-ready. It will require that some stories are broken down, reformulated, etc – and estimations are done using poker planning. A tester or test leader is required to attend here too, so that the formulation of the “how to demo” is really testable and meaningful.

16 comments:

  1. Hi there, awesome site. I thought the topics you posted on were very interesting. I tried to add your RSS to my feed reader and it a few. take a look at it, hopefully I can add you and follow.

    ReplyDelete
  2. This comment has been removed by the author.

    ReplyDelete
  3. Hi friend iam providing the safe agile certification of various Courses online training.

    ReplyDelete
  4. Hi friend iam providing thesafeagile training of various Certification trainings.

    ReplyDelete
  5. COEPD LLC- Center of Excellence for Professional Development is the most trusted online training platform to global participants. We are primarily a community of Business Analysts who have taken the initiative to facilitate professionals of IT or Non IT background with the finest quality training. Our trainings are delivered through interactive mode with illustrative scenarios, activities and case studies to help learners start a successful career. We impart knowledge keeping in view of the challenging situations individuals will face in the real time, so that they can handle their job deliverables with at most confidence.

    https://www.coepd.us/certified-it-scrum-developer.php

    ReplyDelete
  6. Looks like a definition of READY TO PLANNING.
    On my understanding the definition of READY TO SPRINT is a sign off of a member of the DEVELOPMENT TEAM (programmer and or TESTER) that mean :

    I HAVE EVERYTHING THAT IS NEEDED TO COMPLETE (ACCORDING TO THE DEFINITION OF DONE) AUTONOMOUSLY. THEREFORE I CAN COMMIT TO COMPLETE IT DURING A FUTURE ITERATION.

    This is the signal to the PO that he does not need to add any other precision before this task can be completed.

    ReplyDelete
  7. This is the definition of ready who is easily available or obtained; within reach. Check here www.seattletreeremovalpros.com/

    ReplyDelete
  8. Thanks for sharing this.,
    Leanpitch provides online training in CSPO during this lockdown period everyone can use it wisely.
    Join Leanpitch 2 Days CSPO Certification Workshop in different cities.


    CSPO certification online

    ReplyDelete
  9. Hmm , very interesting thoughts! I think In order for more interested people to read your thoughts, you should post it on Instagram, and use the services of https://viplikes.net/buy-instagram-followers to quickly increase the amount of your followers.

    ReplyDelete
  10. he first two are often easy to pinpoint but the purpose is often overlooked, because it feels obvious. fort worth texas drywall contractors

    ReplyDelete
  11. It looks like you spent a lots of time in this article. I truly appreciate your effort you have put in this article. I am impressed by your content. Now its time to avail limousine service Dublin ca for more information.

    ReplyDelete
  12. We use the same story concepts when writing for our blog on waterproofing philadelphia

    ReplyDelete
  13. Awesome topic! 💡 For "Definition of Ready," make sure user stories are crystal clear, acceptance criteria are spot on, and team members are aligned. Ready-ready means smoother sprints! 🚀

    For digital marketing company in noida Visit:- https://www.artattackk.com/

    ReplyDelete