DAD Knowledge Sharing

  • 17 Sep 2018 9:16 AM
    Reply # 6672693 on 3568923

    The INVEST Principle in User Story Writing

    A simple user story template will look like this: As a <user> I want  <feature> so that <value>

    User stories, when used, are at the heart of agile projects as they embody the work that is to be done. The project team creates product increments based primarily on the user stories. The product owner, and entire DAD team for that matter, need to learn how to create user stories that meet the needs of the project goals and objectives. User story writing skills unfortunately, can sometimes be difficult, especially for inexperienced agile practitioners. But the good news is that they can be learned over time. The INVEST principle can help shorten the learning curve.


    The INVEST principle provides a useful concept for writing a good user story. Let's review the meaning of this acronym:

    • Independent - this refers to "order independent." Meaning that you should work towards having stories that can be worked on in any order. This allows for easier prioritization of each user story as dependencies can restrict the ability to implement a valuable and risky story without implementing other much less valuable and risky stories.
    • Negotiable - a story is an invitation to a discussion, so should be the result of collaborative negotiation between relevant stakeholders. The goal is to meet a need and so it is important to understand and agree on what the need is. The key question to ask here is, "how will I know that I've done that?"
    • Valuable - DAD recommends the prioritization of user stories based on value and risk. If a story does not have a discernable value it should not be done. Period! This is the value that we are trying to deliver by completing the user story. It is the "so that <value>" clause in our user story template.
    • Estimable - this refers to the ability to estimate a size for a story relative to the other stories on the work item list or product backlog. Estimating stories is important for the team to be able to prioritize the story and plan iterations and releases. A number of techniques exist for estimating story sizes, including planning poker, "shirt" sizing, Elatta's bucket of complexity, etc. It is advisable that the entire DAD team is involved in the estimation exercise whenever possible.
    • Small - this refers to the time it takes to get the story to a "done" state. Depending on the team and the methodology being used, DAD recommends iterations lasting 2 to 4 weeks. Recommendation is to have user stories that are small enough to allow for no more than an average of 4-5 days of work maximum.
    • Testable - this simply refers to the acceptance criteria for a story. The expectation is that you should be able to write an acceptance criteria for a story immediately. As with Negotiable, the same key question on definition of done works here as well.

     

    So how does this work in principle? You can follow this simple steps:

    1. List the user stories or requirements in a tabular format
    2. Put the INVEST acronyms in columns next to the user stories as shown in the table below
    3. Fill out the matrix as below, setting a cut-off threshold to determine whether a story is acceptable or not.

    The INVEST scale, represented as 1 - 5 and defined here as:

    1 - Definitely not

    2 - Not sure

    3 - Maybe

    4 - Looks like / Kind of

    5 - Definitely

    Example

     User story / Requirement Independent Negotiable  Valuable  Estimable  Small Testable  Total 
      As a Customer I want to Login so that I can access my account  4  2  3  5  3  5  22

     As a Customer I want to register for new online account so I can access my information

     4  4  3  25
     As a developer, I want to design new look and feel for the site  2  4  1  1  2  3  13

    Assuming a threshold of <18, for example,  as a rule that a user story with score of less than 18 points needs to be broken down further to be acceptable. Story 3 with 13 points will need to be broken down further. This threshold is up to the team and will vary based on the project and the team's needs.

    While this might appear daunting, I would recommend that the product owner, and not the entire team does this for the project team. Remember! This is different from user story estimating, which is relevant for prioritization and important that everyone on the team gets involved in where possible. INVESTing in good user stories will ensure that you are working on items that adequately target the business need or problem to be solved and definitely help save you time when estimating story sizes as the stories would have been scaled to where they are easier to understand.

     

    Last modified: 18 Sep 2018 3:41 AM | Ike Emeribe
  • 09 Oct 2015 8:26 AM
    Reply # 3568923 on 3547083

    Test-Driven Development(TDD)



    1. Add a test


    2. Run all the tests with a new feature


    3. See new test fails


    4. Write code


    5. Run all the tests with a new feature


    6. See new test passes


    7. Refactor code


    8. Repeat the steps



    TDD = Test-First Design (TFD) + Refactoring



    Extreme Programming (XP) 



    1. Apply Test-First-Design


    2. Refactor Code


    3.Simple Design


    4. Pair Programming

    Last modified: 09 Oct 2015 8:43 AM | Kaushik Saha
  • 28 Sep 2015 4:00 AM
    Reply # 3549653 on 3547083

    Benefits of DAD over Scrum :

     

    a. Scrum is focused on only "Construction" phase, but DAD is focused on "Inception", "Construction" and "Transition" phase.

     

    b. Scrum delivery is concentrated on "Working Software", but DAD deliverables gives "Complete Solution".

     

    c. Scrum is prescriptive, but DAD is pragmatic ; so DAD is easily tailored.

     

    d. Scrum is targeted from single team to multiple teams ; but DAD is scalable from single team to enterprise.

     

    e. Scrum is one approach process framework, but DAD Life Cycle is the "Hybrid Framework" which includes, Scrum, XP, Lean, Kanban, Continious Delivery, etc.

  • 26 Sep 2015 11:53 AM
    Message # 3547083

    This forum will concentrate on knowledge sharing for "Disciplined Agile Delivery" framework and fundamentals/foundations of DAD.

© 2014-2018 Disciplined Agile Consortium

600 Crowfoot Crescent NW, Suite 340

Calgary, Alberta, CANADA  T3A 5A2

Powered by Wild Apricot Membership Software