For enquiries call:

Phone

+1-469-442-0620

HomeBlogAgileGet ‘Ready’ Before You Get ‘Done’: Productivity Route To The Next Level In Agile

Get ‘Ready’ Before You Get ‘Done’: Productivity Route To The Next Level In Agile

Published
06th May, 2024
Views
view count loader
Read it in
0 Mins
In this article
    Get ‘Ready’ Before You Get ‘Done’: Productivity Route To The Next Level In Agile

    After working with several Agile teams across locations in India, I identified one thing that is imperative for successful Agile Software Development- knowing when you are ready to start. In the Agile world, we call it being “Ready-Ready”. Many times you will see teams kick-starting their software development even before the requirements are laid clearly. Under the misconception of being agile with continuous customer feedback and change, they will end up re-doing software most of the times. Solid software architecture and having a forward-thinking attitude are considered as anti-agile by such teams. Sometimes it becomes a challenge for the Agile preachers in such teams to help the team or the leadership understand the true value and meaning of being Agile.

    No doubt, with Agile comes a freedom to incorporate customer feedback early in the software cycles for more realistic and expected outcomes, but it never says not to perform detailed requirement discussions. A good set of requirements is vital for a good start and spending some time initially to understand the customer’s needs is crucial to a project’s successful execution and delivery.
    With “Ready-Ready”, one cannot only put a tab on the requirements front but also on other crucial aspects that are required for setting the stage right. 

     

    A few key items that I feel should be a part of the ready-ready checklist could be-

    • A story that is prioritized by the Product Owner.
    • A story that has story points assigned to it.
    • A story that contains a ‘Who’ (Persona), ‘What’ (Feature) and ‘Why’ (Benefit).
    • Where an acceptance criteria are defined in the story.
    • Non-Functional Requirements (NFRs) if applicable, are also mentioned in the story.
    • The design is discussed and documented to conform to the current architecture.
    • All dependencies and risks are identified, documented and mitigated.
    • All assumptions are captured in the story.
    • UX is defined for the story’s implementation.
    • Code Reviewers are identified and involved in all related discussions.

    Not all items apply to all teams, but overall these capture the major things that one may miss when starting with a story. For instance, if we do not identify & involve the code reviewer from the beginning, the code review session will end up being a syntax check with almost no focus on the end-to-end functionality and impact on other modules. Likewise, if NFRs are not defined well in advance it can pose a big bottleneck for a software release because of performance issues surfacing later in the development process.

    It becomes very important to ensure that during the backlog grooming sessions, the ready-ready checklist  is looked upon and the stories which score a 10 on the list goes for development in future sprints. Most of the elements are common sense but in the haste of starting development and delivering features we sometimes miss the real basics which we end up paying for, at later stages.

    But it is not only how well you start a story’s execution that matters, closing the story is equally important. Missing a critical element to cater to for a story, can sometimes be disastrous for the whole project. For instance, I read about a team who missed running a check on usage of open-source code snippets in their application code and released the software, they were lashed with huge fines for infringing copyright laws.

    Having a ‘Done-Done’ checklist helps manifold, without that we will never know when a story is done or a feature is complete. In almost all the teams I have worked with, we had a well-defined Done-Done checklist that the team decides early on in the project and adheres to during the course of the project. Having a well-defined ‘Definition of Done’ or ‘Done-Done Checklist’ as I like to call it, not only makes it simple for the team to tick off and claim a story but also gives a clear picture of what is left of the story to push it out of development.
    Most of the items could be very obvious ones such as code checked-in into source control and reviewed etc., but there are a few that I feel are the real value-adds. Listing all that I feel should be a part of a standard Done-Done checklist-

    • High-level design documented.
    • Test Cases discussed among Dev. & Q.A. and documented
    • Unit Tests written ( X% code coverage)
    • Code checked-in into source control
    • Code Reviewed
    • UX Design followed
    • All Unit Tests passing
    • Install/Deployment changes completed & tested
    • Regression is passing
    • Help document updated

    By simply ticking items off this list, teams can be crystal clear with the pending items and focus their attention on the closure of the same. This not only helps the team to drive stories to closure, but also it will help identify any regular roadblocks that hinder a team’s ability to claim story points within a sprint. For instance, team X works on software aspects of a product and is dependent on Y for update of Help & Troubleshooting documentation. Though Y is also involved in many other aspects of the software and Help documentation is not a priority for them. If team X fails to complete a story every sprint because of this dependency, the checklist will eventually highlight the issue and suitable actions can then be taken to prioritize items beyond teams and ensure timely closure.




    Having a comprehensive checklist for both ‘Ready-Ready’ and ‘Done-Done’ sometimes might appear an overkill and some items might even seem too obvious and no-brainer to have on the checklist, but the benefits eventually surface in long term and ultimately help the team to accomplish high quality and on-time delivery of software products.
     

    Earn your PRINCE2 Practitioner certification and become a project management expert with our comprehensive PRINCE2 practitioner certification course. Take your career to new heights with ease.

    Profile

    Lindy Quick

    Blog Author

    Lindy Quick, SPCT, is a dynamic Transformation Architect and Senior Business Agility Consultant with a proven track record of success in driving agile transformations. With expertise in multiple agile frameworks, including SAFe, Scrum, and Kanban, Lindy has led impactful transformations across diverse industries such as manufacturing, defense, insurance/financial, and federal government. Lindy's exceptional communication, leadership, and problem-solving skills have earned her a reputation as a trusted advisor. Currently associated with KnowledgeHut and upGrad, Lindy fosters Lean-Agile principles and mindset through coaching, training, and successful execution of transformations. With a passion for effective value delivery, Lindy is a sought-after expert in the field.

    Share This Article
    Ready to Master the Skills that Drive Your Career?

    Avail your free 1:1 mentorship session.

    Select
    Your Message (Optional)

    Upcoming Agile Management Batches & Dates

    NameDateFeeKnow more
    Course advisor icon
    Offer
    Whatsapp/Chat icon