Design a site like this with
Get started

Managing the iteration Flow–Getting Ready-Ready for user stories in an agile iteration

Agile team needs to get their user stories ready for development before they can be picked for implementation in iteration (Sprints of Scrum). Un-groomed, un-prepared stories, prioritized for implementation in iteration, waste development cycles, and diverts team’s focus from the planned iteration activities and tasks.
Agile teamProduct owners(primarily responsible) and development team members, work on user stories grooming in advance, to ensure that by the time the user stories are prioritized for implementation in iteration, they have enough information to be consumed by development team. This early user stories preparation leads to reduced cycle times and smaller queues for user stories’ unblocked tasks. It creates a pull system for user stories to seamlessly flow from start-to-end of an agile iteration without any impediments and delays.
This early preparation of user stories by ‘Product owner’ with the help of other stakeholders (marketing, support and anyone who can help in clarifying the needs and requirements related to user story) and the development team in getting the user stories ready or ‘Ready-Ready’(as they call it in scrum) for implementation.
This paper answers important questions related to getting ‘Ready-Ready for user stories’ before the start of the iteration.

Following questions are answered in this article:
  • What is ‘Definition of Ready’ (DOR) for a user story in agile iterations?
  • Why do we need to be ‘Ready-Ready for a user story’ before agile iterations?  
  • How can we ensure that we are Ready-Ready for user story?
  •  What is the advice to agile teams getting ‘Ready-Ready for user story’?

What is ‘Definition of Ready’ (DOR) for a user story in agile iterations?  

‘Definition of Ready (DOR)’ is a ‘set of agreements’ for shared understanding of user story in a focused agile team. It signifies that the user story is ready, with all conditions satisfied, for implementation in upcoming iteration. User story should be actionable by agile team during the iteration, so that they can be consumed quickly for implementation. They should get Done-Done without impediments.

Why do we need to be ‘Ready-Ready for a user story’ before agile iterations?

Getting ‘Ready-Ready for user story’ has significant impacts on various aspects of   iterative agile development (scrum sprints).

 Following are some categorized impacts of getting ‘Ready-Ready for user story’.
   1. Ready-Ready impacts on building (and discovering) knowledge and a shared-understanding of the user story in agile team for seamless (effortless) implementation in upcoming iteration.
     The Product owner and the implementation team work at different cadences. Their focus, involvement and understanding of a user story are different at different times, i.e. before and during the iteration. Product owner may have more knowledge (not mandatory though) on the user story before the user story is prioritized for iteration, or at the beginning of the iteration. After the user story is part of iteration delivery plan, implementation team will develop more knowledge and understanding of user story, through continuous dialogues and discussions with the product owner. Irrespective of the differences in focus, involvement and understanding of user stories, all team members-product owner and development team, work together on a common goal of achieving a successful iteration and a successful product.
Time-boxed iterations (as in Scrum) are one way to synchronize Product owner and implementation teams different areas of focus; beginning of iteration is where the mental model synching can happen. If we have a set of user stories with clear Definition of Ready’ or Ready-Ready state at the beginning of iteration, it serves as a synchronization point between Product owner and implementation team. It brings everyone on the common platform right at the start of iteration. ‘Well Begun Is Half Done’ – Aristotle.
    Ready-Ready helps the team to focus on value-added discussions on the problem to be solved. It removes all unwanted, non-value adding activities around  the user story discussions and elaborations.
     Ready-Ready for user story helps in clarifying the basic acceptance criteria’s for the user story. Implementation teams will have solid foundations to conduct right contextual dialogues for elaboration of user story during the iteration.
       2.  Ready-Ready impacts on iteration flow.
     Ready-Ready for user story helps in creating a flow in iteration. It helps in reducing the waiting queues at the start of implementation; it reduces the cycle time of user stories implementation; and creates a pull system where the user stories are quickly pulled, designed, developed, tested and delivered in a iteration., i.e. taking them from Ready-Ready to Done-Done state quickly.  Also, since there is a good shared-understanding of the user story acceptance criteria’s, the design and development tasks related to the user stories can be organized in smaller batches to flow to the next stage (designàdevelopmentàtesting)of development. It enables continuous testing and feedback.
      Ready-Ready for user story let’s everyone in the team know when a user story can be taken into sprint for implementation. It does not need to be “100% accurately defined”, and detailed out with all acceptance criteria; it should have enough details and initial cover-up discussions to get the development started.
      Ready-Ready for user story reduces disruptions and waste caused by context-switching in agile teams— a lean iteration. Since the team are focused, they clearly know the right details of user story. The time spent in basic clarifications, evaluation, and unwanted experimentation is reduced. Note: User stories driven development still requires open conversation in team to succeed.  Remember 3C of User stories – Card, Conversation, and Confirmation.
      Ready-Ready for user story increases the velocity of the team. Since the user stories are already prepared for implementation, team can consume them quickly. It increases the team’s ability to complete more story points and hence increases their iteration velocity.
      Ready-Ready for user story increases the probability of successful iteration (sprint). Team’s chances to deliver the committed items for the iteration increases. It will create wider acceptance of agile programs as the stakeholders will be able to see the results quickly—the working code.
        3. Ready-Ready impacts on the quality of work done.

    Ready-Ready for user story’ reduces the complexity of the user story. Ready-Ready requires story to be small enough to be completed in iteration. Small stories are less complex and better understood by implementation team. They can be implemented without any impediments with better quality.

    Well groomed user stories encourage insightful dialogues, good discussions, more participations, clear acceptance criteria’s and shared-knowledge. All these, contribute to the quality of the iteration deliverable.

    Ready-Ready for user story helps in minimizing the re-work, and maximizing creativity, and quality of deliverables.

        4. Ready impacts on the agile team’s motivation and commitments.
      Ready-Ready for user story increases the commitment and confidence of the team for accepted and committed work during the iteration. It eliminates all unknowns that hinder the right implementation of user stories; increasing the confidence level in the agile team. Of course, when we are clear on what has to be done, we show more confidence to complete it.
      Ready-Ready for user story helps the ‘Product owner’ to gain confidence of the implementation team. She feels ‘involved’ right at the start of iteration which further helps in building an environment of open dialogues and conversation between team members.
      Ready-Ready for user story will have impacts on the morale and motivation of the team. Team will have more control on the delivery of the committed work. It will increase the self-organization capabilities of the team; it will develop trust in stakeholders for the agile team; it will facilitate teamwork; and it will increase the collaboration between the implementation team and the product owner. 

         How can we ensure that we are Ready-Ready for user story?

Ready-Ready for user stories can be presented as guidelines or checklist for agile iterations. It depends on the team and how they want to incorporate it. Agile teams should remember that the Ready-Ready for user story is an evolving phenomenon. There is no fixed check-list which can be used. It will change based on the context of iteration. There will be some basic guidelines (checklist items) which will be common across all Ready-Ready user stories preparations.

They can be classified in following two 2 categories:

  1.  Common ‘Ready-Ready for user story’ guidelines and checklist: They will be common across all types of use stories
  2. Context specific guidelines for ‘Ready-Ready for user story’: This will depend on the type of user stories we are developing in iteration. E.g. User stories around user interface development will have ‘UI mock-ups or wire frames’ in the Ready-ready list or required architecture guidelines and diagrams.
    We discuss some Common ‘Ready-Ready for user story’ guidelines here.

Checklist for assessing the readiness for ‘Ready-Ready for user story’

(In no specific order)      


‘Ready-Ready for user stories’ check


Are we doing it? Yes/No


Is the user story well defined?

The Actor (Who is doing the action. ‘AS A’), The Action (work done, ‘I WANT’) and Purpose (value addition in performing the action, ‘SO THAT’) should be clearly conveyed in the user story.

User story template – ‘‘AS A’ I WANT SO THAT ”.



Do the user story follow the INVEST model?


The INVEST model for user story:
Independent: The story stands alone with no dependencies.
Negotiable: Story should act as a starting point of conversation during the iteration. This conversation between team members will result in details about the implemented functionality and the acceptance criteria.
Valuable: It should demonstrate some well understood value to end customer.
Estimable: Known story points for the user story to be completed within iteration.
Small:  A story should not take longer than a sprint to finish 
Testable: It should be easy to define and test the acceptance criteria’s. 



Are we confident about the value and intent of the user story?


Does everyone agree on the viability and usefulness of the user story?  

Which means everyone agrees that user story is important for the product and should be immediately implemented to meet the product goals.



Are all known basic user story acceptance criteria defined?


It does not need to be all acceptance criteria’s upfront. Most of them will be discovered when conversation on user story happens during the iteration. Basic expected behaviour of the user story should be clearly understood, and communicated.



Are all dependencies of user story identified?


Tight coupling between the user stories make them difficult for prioritization and estimation. User stories can be split into two or smaller user stories or they can be combined together to be completed in single iteration to reduce the dependencies and its impacts on the readiness of the user story for iteration.
e.g., Do we need to complete some other tasks before picking this user story? Do we need to wait for availability of some items (code, components, design etc.) from other teams?
Have the dependencies among different user stories in the backlog sorted out? etc.



Is the user story sized and estimable by team? 


The early estimation of the user story is possible if we know the following:
Do I have a realistic knowledge on how long it is going to take to build the user story?  It won’t be right, but it needs to be a reasonable estimate given all that I know. 
Do we know at a fairly high level about the tasks to be done to complete the user story?
Do we know the story points (measure for user story) required for the user story? 
Do we know our velocity (capacity and speed at which we can complete story points) for iteration?
Do we need to merge or split the user story into more granular stories for better estimation? User story should be short enough to be implemented in single iteration. Otherwise it needs to be split into two or more user stories.



Have we identified the owner; the person who will accept the user story after it is completed in iteration?

This has to be the product owner in most of the cases. Except for technical user stories owned by engineering team.
e.g. Development of a product infrastructure component. 



Have we given some thoughts on how the user story will be implemented? 

Do we need (or have) higher level solution design for the user story?   
e.g. early UML class and sequence diagrams, or just white board sketches can help in knowing how the pieces work together.




Have we identified all implementation impacts of user story? 


1. Are there any critical design or architecture changes? 
2. Are there any impacts on the implemented code?  
3. Do we need any refactoring of existing code?
4. Are there any code flow change? If yes, do we know, how will we validate the code flow or any behavioural changes?



Has the implementation team accepted the User Experience (UX) artefacts (if any)?


Basic Wireframes or UI mock-ups should be available.



Do we have good idea on what it will take to demo the user story?


Understanding of, what it will take to demonstrate a user story will give team an insight into the user story integration and deployment requirements. It can uncover unknown constraints for user story implementation and acceptance.




Has product owner committed and signed for the user story? 


Product owner commitment is important for acceptance of user story.



Do we have our development environment ready for user story? 


Any specific server, package, library etc. required?



Do we know all the required non-functional requirements (Quality concerns: performance, scalability, availability testability, etc.) which will be affected by this user story?  


Non-functional requirements (NFR) are cross cutting concerns spanning across multiple user stories implementations. User stories implementations should address these NFRs (or product quality concerns). The components created, and their implemented functionalities should positively enable required quality concerns. Create a matrix for NFR vs. components or classes created, modified and impacted by user story. Some early understanding of these NFRs, helps in reducing the design and development time of user story. It also helps in reducing any later re-work that is done to address these quality concerns. Build the NFR into the user story design and implementation.



Can we implement this story in iteration?

Do we need to break the story into two or more stories?

Do we need to apply some constraints to the user story?


User story should be a single iteration consumable unit. Large user stories are complex and difficult to understand, debate, implement and test. Keep it small and manageable.

User stories may have dependencies on other pending user stories, availability of external libraries or API’s etc.
Knowledge of Non-functional requirements like performance, interoperability, robustness, availability etc. will also constrain and impact the readiness of the user story.



Are we making any assumptions related to user stories?


State all assumptions related to user story. Assumptions can arise due to solution boundaries or due to lack of information.



Do we have clear and shared-understanding of product and design principles and goals in context of user story?


Prioritized Product and Design principles will help the team on the following:
        1) To help in making right design trade-off decisions. They serve as clear statements of what the team believe and agree on the purpose of product and design.   
        2) They help in setting right stage for constructive debate, and arguments within team about the user story.
         3) They create visibility and clarity in decision making, and reasoning during the user story conversation.
Product principles:  Product principles guide the user story purpose. They are foundation for user story elaboration discussions; that take place in the team between developers and product owners. They bring together the product owner and implementation team on common platform. Product principles should be prioritized for clear understanding, and use in product decision making.  E.g. What is more important for current release? – High usability or increased scalability to handle rapid user additions with acceptable and simple usability. 
Design principles: Design principles guide the design and architecture strategy. They help in making important design trade-offs. T
Together, the clear and shared product and design principles can really ensure a smooth start of iteration. It will resolve design conflicts, help in design and implementation feasibility assessment, and quick user story acceptance and development. It helps in ensuring effective process for making early, informed, product and design decisions in iteration.

e.g.  Do we need to open our API’s for user access?

This will depend on out product strategy, which, if yes, will influence the user story design and time lines. It is good to know these details in advance.



Are there any requirements for specific technical skills and knowledge? 

External expertise like UI design experts, database expert etc.




What is the advice to agile teams getting ‘Ready-Ready for user story’?

Ready-Ready for user story’ definition will evolve. There are no specific template guidelines or checklist for ‘Ready-Ready for user story’. Depending on the context of the product, teams (skills, knowledge, involvement etc.), and type of user stories in iteration, these guidelines will evolve. Idea is to continuously brainstorm and retrospect during iteration, to create a dynamic, evolving list of ‘Ready-Ready user story’ guidelines. Include, what works, and makes the task of implementation of user story easy; exclude others non-value adding, squandering activities. The Ready-Ready checklist is a living document and should be kept up-to date with iteration feedback.
Getting ‘’Ready-Ready for user story’ is everyone’s responsibility. Though product owner is primarily responsible for getting the prioritized product-backlog user stories ready before iteration; it requires everyone’s involvements. At least, the key stake holders from the development team should be part of the process. Scrum Master, Business Analyst, team members, and anyone, who can be pulled to get the required user story details, should participate. Cross-functional agile teams should be responsible for creation, assessment, agreement and adherence to Ready-Ready.
Specific elements of ‘Ready-Ready for user story’ will likely be different for every team and project but there will be common elements across these scenarios. Once successfully implemented in one team, the concepts and knowledge acquired can be transferred and replicated to product iterations.
Iteration retrospection is a great source of feedback on ‘Ready-Ready for user story’. Ensure that Ready-Ready issues, and required improvements, are discussed during iteration retrospection meetings. Prepare to incorporate suggestions on Ready-Ready immediately in next iteration. Note: Ready-Ready creation is an evolving process.
Product owner should commit to Ready-ready. Product owners should take a lead in defining the Ready-Ready for user story criteria’s. Product owners’ full involvement and commitment is necessary for its success. Getting to the state of Ready-Ready for user story will require preparation from product owner before the user story is considered for iteration. Product owner should continuously refine, prune and groom the prioritized user stories in the product backlog before they become part of the iteration (sprint) backlog. Some upfront discussions before the start of iteration will ensure acceptance of desirability (what is needed?), viability (value addition), feasibility (implementation and experimentation) of user story for agile implementation team
Product owners should groom the epics and use stories in the product backlog in advance. Usually, having product grooming cycles half or one iteration in advance, before the user story is actually prioritized for the iteration is a good idea. Recent retrospections on Ready-Ready inputs are valuable and they can be incorporated quickly for Ready-Ready improvements. Doing it ‘too early’ or ‘too late’ will create issues. Doing it ‘too early’ will miss the retrospection inputs. Doing it ‘too late’, will not leave enough time with the team to uncover and unblock the unknown risks associated with the user story. It will still require some upfront planning from the implementation team to discuss (with product owner), and get the user story in Ready-Ready state.
Only Ready-Ready user stories should be scheduled for iterations. Scrum master should ensure that only Ready-Ready user stories are scheduled for implementation in iteration.
Getting Ready-Ready for user story should be a planned activity. Scrum master should dedicate time during iteration to participate in grooming exercise for getting the prioritized user stories Ready-Ready for next iteration.  As discussed, the goal of preparing the user stories for the next sprint and allocating time for it will increase the overall flow during future iterations.

MindMap files

 1) FreeMind mind map files( format) are available for download. ->Click here.

 2) Click the image below to get the jpeg for mind map(best viewed in Chrome browser with zoom).

Ready-Ready for user story

Author: Tribhuwan

I am Tribhuwan Negi. I have been a technology evangelist and enthusiast having wide areas of interest in the field of software development and engineering. I have experience in architecting and designing enterprises applications, integration and middle-ware application solutions. I have worked on computational data grids(fabrics), distributed caching, data retrieval systems, complex event processing engines. I have also worked with CADCAM, process engineering and robotic simulations. I have lead teams on complete SDLC cycle. I have worked with start-ups and practiced agile software development. I work on different roles of developer, tech lead, engineering manager, software architect and scrum master. I have Bachelor and Masters Degree in Engineering from Indian Institute of Technology(IIT), Bombay.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: