Back to blogs

‘Ready’ for Implementation, ‘Done’ for Deployment!!

Read it in 4 Mins

Last updated on
08th Jun, 2022
Published
30th Jun, 2017
Views
1,203
‘Ready’ for Implementation, ‘Done’ for Deployment!!

Agile projects are driven by the need for continuous progress and by the need of making that progress visible. Progress made is made visible through the different agile project management tools used, such as JIRA, Trello, TFS, RTM or even using a simple MS Excel tracking sheet. In this article I am going to discuss about two key statuses that can be seen in an agile project environment.

The ‘Ready’ status in agile projects has its own definition and explanation. Imagine a young lady getting ready to go for an evening wedding. She would spend a good two to three hours getting ready starting for a wash, a facial, a makeup, wearing the dress, hair dressing to wearing jewelry and so on. There is a list of tasks that she’d go through in her head before finally coming out of her dressing room confidently telling her husband, ‘Honey, I’m ready!!’. ☺

Getting ‘Ready’ in Agile is no different and is related to requirements. Specifically it is with regards to user stories, which are the primary form of documentation of requirements in, Agile. All user stories that have been considered as ‘potential candidates’ for the upcoming sprint MUST be in ‘Ready’ status before the team meets up for the Sprint Planning session.

How can we confidently say that the requirements are ‘Ready’ for implementation? It is more of a gut feeling rather than something set in stone. It is subjective and may differ from team to team. It can be identified as when the team is confident enough to say that they have adequate information to start designing and implementing the selected user story.

The following can be a possible checklist that can be used to check the readiness of a story. Again, this is not set in stone. The team is free to define their own checklist for this purpose.

Checklist to ascertain readiness of user stories:

  • Requirements elaborated in detail along with appropriate acceptance criteria being defined
  • ‘Conversation’ on user stories has happened and findings recorded on the ‘Card’
  • UI / UX completed (only if UI is applicable)
  • Effort to implement the story has been estimated as story points (by involving everyone in the implementation team)
  • Requirement has been Peer reviewed and / or lead reviewed
  • Review comments incorporated
  • Walkthrough of the story during backlog grooming / story refinement sessions has been done with the development team

Note: Development team in Agile projects does not mean only the dev team but includes everyone in the implementation team

  • Story is refined based on the feedback received from the implementation team and the story point estimation is confirmed
  • User story is approved by business where the priority and business criticality has been confirmed

The above mentioned checklist can be checked as a guideline for any given user story. If the team agrees that all criteria have been ticked then it means that the user story is ready for consideration during the upcoming sprint.

Note again that above is just a guideline. For example, the checklist of another team may not have the checklist item of having the UI / UX completed for the story but they may take it up as a task to be done during the sprint.

While the definition of ready is being proactive, the definition of done is essential to validate that the feature defined in the story has been implemented properly.

Same as with the definition of ‘Ready’, the status ‘Done’ for user stories has a different meaning in an agile environment. For any feature implemented to be deployed into a production environment, the user story MUST be in ‘Done’ state.

Checklist to ascertain whether a story can be marked as ‘Done’

  • Test case preparation completed
  • Test case review (peer review / lead review) completed
  • Feature implementation completed
  • Unit testing completed
  • Code review completed
  • QA testing completed (Feature testing, Integration testing, Regression testing and NFR testing is completed)
  • Feature demonstration to project stakeholders is completed
  • Business review comments are recorded and analyzed – based on the analysis of review comments new user stories to incorporate changes may be identified for future sprints.

Once the aforementioned checklist is checked for any user story implemented during the sprint, that user story may be marked as ‘Done’ if no more work is pending for the same.

What happens if any of the checklist items is not complete?

If any of the items on the checklist are not complete, ideally the story should not be marked as ‘Done’. It simply means that the feature implementation has not gone through all the stage gates in place to ascertain whether the feature has been implemented properly. However, with the discretion of the customer or the product owner, the team may agree to mark a story as ‘Done’ even if a story has not passed through all the stage gates in the checklist. However, this is not recommended but must be done only if everyone is in agreement.

Profile

Rumesh Wijetunge

Chief Innovation Officer - Zaizi Limited, Chief Operating Officer - LearntIn (Pvt) Ltd., Director /

Rumesh is an IT business leader with over 12 years of industry experience as a business analyst and project manager. He is currently the CIO of Zaizi Limited, a UK based data management company heading the operations in Sri Lanka, the COO of LearntIn, a global training institute based in Sri Lanka and is also a lecturer / trainer at multiple private universities on management, IT, business analysis and project management subjects. He is the current president of the IIBA Sri Lanka chapter and is one of the most qualified and sought after trainers in Sri Lanka. Refer his LinkedIn profile for more details and to see more articles he has written on linkedin

Trending Blog

6