Test Requirement Driven Development(TREDD) places a renewed emphasis on quality and accountability, and provides the insight to allow your product development and management teams to make the necessary changes in order to produce outstanding quality products on schedule, in a cost-efficient and highly collaborative manner.

What separates TREDD from other development methodologies like TDD (test driven development), ATDD (acceptance test drive development), or BDD (behavior driven development), is the status of the test requirement when the product development lifecycle concludes.

Test Requirement status is the breakthrough element that allows test requirement to provide an objective measurement to the quality of the product development team, so that adjustments can be made for subsequent product development iterations that will ensure quality improves, as well as increase the effectiveness of the product development team.

Come and learn how your TREDD will catalyze your SCRUM team toward greater capabilities, quality, accountability, and satisfaction!

0 favorite thumb_down thumb_up 9 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist

Outline/Structure of the Demonstration

The structure will be a powerpoint presentation with interactive audience participation.

Learning Outcome

With this presentation, the attendees will discover a new quest for quality and accountability that will transform their SCRUM teams and implementation into high producing Product Development Teams!

Target Audience

SCRUM Masters, Quality Analysts, Business Analysts, Product Owners, Senior Management

schedule Submitted 6 years ago

Public Feedback

comment Suggest improvements to the Speaker
  • Deepak Dhananjaya
    By Deepak Dhananjaya  ~  3 years ago
    reply Reply

    Could you provide some examples so we understand this better? and see if its different from what we are getting?

    • Michael O
      By Michael O'Reilly  ~  5 years ago
      reply Reply

      Examples will be covered in the presentation.  You can also find examples in the TREDD book.

  • gnuyoga
    By gnuyoga  ~  5 years ago
    reply Reply

    Hi Michael,

    Very intesreting topic. I was under the impression that Collaboration, Accountability, Quality is basic tenant of Agile team ? I do see that you are bringout some good pointers developers, testers should keep in mind while working in a Agile team, which is great.  Have you presented the same in other conference ? what was the response like ? Will be great to see a video you presenting in past conferences. 



    • Michael O
      By Michael O'Reilly  ~  5 years ago
      reply Reply

      S (?),


      For an Agile team, there are many basic tenants, but these three are essential to keep in the forefront.  These three in particular will get lost as the team hurrys toward development.  Quality is essential for efficiency.  The concept that is is acceptable to have developers produce code that is defective, should not be acceptatible.  Having stories that can be built, but not sent to production also shows poor quality of contribution.  Accountability and Collaboration are also very important to stress in the team so that the "waterfall" structure is diffused and talent is promoted beyond the members roles.  This has show to be very successful in the many instances where I have turned low performing agile teams, into high producing Agile powerhouses!

      Unfortunately I do not have any videoes of past conference presentations.  My presentation is entertaining, fast moving, and thought provoking.  I encourages the attending to consider their existing development cycle paradigms.

      I hope this helps give you some additional insight.


      - Mike

  • Michael O
    By Michael O'Reilly  ~  5 years ago
    reply Reply

    Thanks for your interest and inquiry.  Let me address your question by explaining Test Requirements a little further.

    Test Requirement Driven Development reshapes the acceptance criteria around the TEST REQUIREMENT, to provide the SCRUM or Product Development Team a new focus on:

    • ·         Collaboration
    • ·         Accountability
    • ·         Quality

    Let me explain briefly:


    Software testers, will really appreciate that Test Requirements are very similar to a test case.  Test cases are basically functional definitions for how the product should perform at the end of the iteration created by the testing team (sometimes called Quality Assurance).  TREDD moves the test case definition to the beginning of the iteration.  The test case becomes the Test Requirement.  This Enables the entire team visibility of these requirements and spurs on collaboration, communication, and consensus regarding what that functional requirements are, how can it be developed, and verified.  This means that the product is built with quality at the beginning engaging the contributions of the software testers.

    Two points are important to consider.  First, is that the Test Requirements can be defined throughout the iteration, but have greatest value at the beginning.  Anyone on the team can is expected to add Test Requirements.  If a developer sees a condition that he needs to code for, they will first create the Test Requirement, and then code.  This is similar to Test Driven Development.

    Second consideration is the Test Requirement is not a new effort for the team.  It is moving the effort of the software testers towards the front of the iteration.  In most cases, the software testers create test cases are within their own view to be executed after they receive software from the developers. TREDD shifts this effort to a more beneficial time frame.


    Test Requirements are written to possess single, not composite, functionality.  The developer creates the product or software to satisfy the Test Requirement.  They are also responsible for executing the Test Requirement prior to final quality verification of that iteration.  If it is not functioning as expected, then there is direct accountability to the developer who signed off that it was tested to be functional (unless they said it wasn’t of course). 

    Likewise, Test Requirements are defined with authorship signoff.  Test Requirements which are created with little practical value or beyond the scope of the User Story, the author is accountable for defining  that particular Test Requirements.  They are accountable to the team for being a source of possible distraction during the iteration.


    Acceptance Criteria has no traceability attributes.  They just are defined with the User Story.  The Test Requirement however has 4 classifications.  These classifications provide leading indicators for the quality contributions of the SCRUM (or Product) development team members.  Using these classifications enables the team and management to make adjustments within or immediately after the iteration to improve team performance, which means better quality, timely deliverables, and reduced cost.


    My presentation will provide additional insight as does my book Test Requirement Driven Development which is currently available on Amazon.com.    I hope this summary helps you better understand how TREDD provides greater value to the product development lifecycle than well-formed acceptance criteria.

  • Ellen Grove
    By Ellen Grove  ~  6 years ago
    reply Reply

    I've been to the blog and viewed the slides, and I'm still not clear on how TREDD differs from having well-formed Acceptance Criteria (I'm a software tester by technical background).  Can you tell me a little more so that I understand the essence of your proposal?  

    Also, have you any real-world examples of how TREDD has been used in the wild? That's one thing I would really like to see in this proposal.

    • Michael O
      By Michael O'Reilly  ~  5 years ago
      reply Reply

      Ellen, please see my posting

  • Steve Ropa
    By Steve Ropa  ~  6 years ago
    reply Reply

    Just to echo Ellen here, can you tell us how this is different from well formed Acceptance Criteria/Tests?

    • Michael O
      By Michael O'Reilly  ~  5 years ago
      reply Reply

      Steve, please see my posting.