All of the Core Agile Team members are either a daily member of the Sprint Team or has a designated daily representative as a Sprint Team member.

The team representatives can be rotated but a daily representative must be available for the Daily Stand Up Scrum meetings.

The representative will be required to pass on to their team members all relevant information and discovered development blocks that they are involved with to help solve.

The success of the Sprint team is the responsibility of the Scrum Master.

The Scrum Master owns the Sprint team and runs the Daily Sprint Stand-up meetings.

There Should be One Scrum Master

… Per Sprint Development Team

The Scrum Master manages the Sprint Metrics for their team.

The Scrum Master tracks the development task Burn Up, and possibly the Burn Down, which represents the current iteration development progress.

The development Velocity of the team is tracked and managed by the Scrum Master as well.

The Scrum Master role can delegate the Sprint Metrics responsibilities to other team members.

The Results of Sprint Metric Management

… Are Always the Scrum Master’s Responsibility

When development requires “Cutting Corners” to make a release deployment date it is charged on the “Technical Debt” credit card.

The Scrum Master is responsible for paying down the debt through end of Sprint task assignments to developers who have completed their Sprint assignments on-time.

The Scrum Master creates these tasks for the Backlog listings and informs the owner of the Backlog, The Product Owner, of these additions.

The Scrum Master is in constant contact with the Product Owner to make sure that understanding of the goals of the Business Stakeholders are always driving the daily development activities.

The success of the development process in the eyes of the Business Team is the primary responsibility of the Product Owner

This role is the equivalent of the Customer Liaison in a traditional Waterfall development methodology.

The Product Owner must understand the outcome of the Technology solutions but not necessarily the Technologies themselves.

The Product Owner must have an expert knowledge of the Client’s “Problem Domain” and a clear vision for communication, based on the Ubiquitous Language, for the successful delivery of the vision of the Business Stakeholders for the engagement.

The Product Owner manages the Business defined Task Backlog.

This includes the list of “Would Like to Have” items commonly referred to as the “The Christmas List”.

When development requires “Cutting Corners” to make a release deployment date it is charged on the “Technical Debt” credit card.

The Product owner is aware of these charges but the Scrum Master is responsible for paying down the debt through end of Sprint task assignments to developers who have completed their Sprint assignments on-time.

The Scrum Master is the primary member of the Sprint Team that the Product Owner communicates with on a daily basis.

There are a number of types of releases of developed product in traditional software development for commercially marketed products:

Main releases

1. Alpha
2. Beta
3. Release To Market (RTM)

Service pack releases

1. Patch
2. Hotfix

If you are creating in-house applications you may have release types:

Product releases

1. Staging – Preproduction environment
2. Production – Customer facing release

Scheduled Update releases

1. Staging
2. Production

The each business environment is unique and the names are not really important.

What is important is that a well-disciplined methodology be developed, matured and consistanly implemented

The success of the communication process is the primary responsibility of the Lexicon Master.

This role manages the Ubiquitous Language, the language of understanding used by all of the engagement Agile Team members.

This common language is used in all written, verbal, formal and informal communications and is the driving naming convention for the Technology Domain Code Models.

The Lexicon Master uses a special email address that is on every distribution list used by the Agile Teams.

The communications are scanned for any new or changes in the use of defined terms.

The Lexicon Master Skill sets are those of a traditional Technology Writer.

The understanding of the Technology is not required and actually a minimum knowledge of the engagement Technologies is a requirement for this position.

The Lexicon Master initiates the Change Management Due Diligence process to evaluate any change for the engagement’s communication language.

This change includes Resource requirements to refactor the Domain Models, the cost of the Resources and the Cost/Benefit Ratio of the discovered language change.

Changes to the Lexicon are expensive as all Developed Code, Statement of Works and Supporting Documentation must be updated with the approved language change.

The Lexicon Master is a “Listening Member” of the Daily Stand Up meeting and speaks only when an established or new term is in question.

The daily integrity of the Agile Team’s common communication language is the responsibility of the Lexicon Master.

The Business Team consists of the following roles:

1. Business Stakeholders
2. Subject Matter Experts
3. Business Analysts
4. Program Manager
5. Product Owner
6. Scrum Master
7. Lexicon Master

The success of the engagement is predicated on a crystal clear understanding of the expectations of the Business Domain Experts.

The Business Domain Experts are the Stakeholders, Subject Matter Experts, and the Business Analysts.

The Program Manager, Product Owner, Scrum Masters and the Ubiquitous Language’s Lexicon Master are engagement resources and are generally provided by the Technology Solution Provider.

The vision of the Client, through its team members, is communicated to the Sprint Team by the Business Team Representatives

The  Business Team Representatives are members of the Sprint Team.

A Business Team Representative must be present at all Daily Stand Up meeting as a “Listening Member” to identify any misunderstandings in the Technology Domain versus the Business Domain.

The Business Team Representative helps solve any blocks to that vision through the Domain Knowledge and is supported by the Business Team members.

The Product Owner works with the Business Team Representatives to help communicate the expectations to the Scrum Master.

This role can be delegated to any member of the Business Domain Expert team.

This role speaks during the Daily Stand Up meetings only when an issue is recognized or a Development Block is raised that pertains to an understanding of the Business Domain.

Business Team Representative communicates with other Business Stakeholders and Subject Matter Experts team members to helps solve the block.

The Scrum Master and Product Owner work with the Architecture Team to relay the knowledge disseminated by the Business Team regarding any misunderstanding or Blocks discovered during the Daily Stand Up meetings

The Architect Team consists of the following roles:

1. Applications Architects
2. Systems Architectures
3. Designers
4. Data Architects
5. Database Analysts

The entire Architect team works to create the Domain Driven Design (DDD) based Technology Domain Models.

These Domain Models from the Technology “Bounded Contexts”.

The Bounded Contexts are created from the knowledge gained by the Business Team about the “Troubled Domain”: The Business Domain.

The Database Architects and the Database Analysts work with the Business Team’s Business Analysts and the Domain Subject Matter Experts to create the Domain Models abstractions.

These abstractions are delivered to the Architects and will be used to create the designs for the User Story Acceptance Criteria delivered by the Business Stakeholders to the Product Owner for development.

The User Story Acceptance Criteria, in Story Points, is transformed into Behavior Driven Design (BDD) Development Task Scenarios from User Story Points by the Architects.

The Designers receive the upcoming Sprints BDD Task Scenarios from the Backlog Items selected for the upcoming Sprint iteration.

The Business Stakeholders always define the priority of Development of the Backlog items.

The BDD Scenarios for the new Sprint are selected by the Product Owner from the Sprint Backlog as per the Business Stakeholder’s.

The BDD Scenarios are now ready for Development Task Estimation in an “Hours from Points” estimation process.

A Formal Design Review is held to certified that the Formal Design document meets the Business Objectives as defined by the Business Team.

The Developers accept their Task assignments in accordance to their agreed upon Development Capacity, in daily development hours, for the upcoming Sprint once the Formal Design has been certified.

A Development Team consists of the following roles:

1. Development Lead
2. UI Developers
3. Application Developers
4. Back End Developers
5. Database Developers
6. Business Intelligence Developers
7. Continuous Integration Manager
8. Code Review Lead
9. Code Technologist

All of the Development role members are contributing members of the Daily Stand Up meeting.

The Sprint iteration consists of one or more Sprint Teams.

Each team is populated with members of a Development Team.

Not all of the roles listed above will be members of every team.

The responsibilities of some of the roles can be held by a single developer.

There are some rules about multiple roles:

1. The Code Review Lead – A Developer cannot be assigned to this role if the code being reviewed was created by this developer. This role is a Developer but the capacity hours must be reduced to support the time required for the Code Review planning and execution.
2. The Code Technologist – This role creates depth of knowledge for the delivered code base and cannot be assigned to a Developer who created the code being reviewed. A Developer should only be assigned to one code review session per Sprint, if possible. A session can be held for multiple Developers’ code base review.
3. The Continuous Integration Manager – This role is a Developer but the capacity hours must be reduced to support the time required each day to guarantee a Good Daily Build and Smoke Test
4. Team Rotating Roles – The roles of Continuous Integration Manager, Code Review Manager, Code Review Lead and Code Technologist are Team rotated roles
5. Sprint Assigned Roles – The Continuous Integration Manager and the Code Review Manager are rotated each Sprint iteration. The last two days of the Sprint the roles are passed on to the new assignments as part of the Sprint Planning process.

All Developers speak during the Daily Stand Up meetings.

The Sprint Stand Up Meeting Reporting Format is:

1. What did you do yesterday? – A short description of your activities without any details of those activities. The justification of this activity is Sprint Team awareness of daily activities not details of them.
2. What are you planning to do today? – A short description of your planned development activities without any details of those activities. This gives the Sprint Team an understanding of the direction of the development activities. Any issues that might affect other development activities would be brought to light with this process.
3. Do you have any blocks? – This final answer in the Daily Stand Up process is the reason that all Agile Team members must be involved in the Daily Stand Up meeting. With representation of all of the engagement team present, in-person or by conference call, issues can be resolved quickly. The Scrum Master determines if a block can be removed in this Sprint or sent to the Sprint Backlog for assessment for the next Sprint iteration. This activity frees the Developer to move to the next Sprint task assigned until the resolution of the block is known.

Code Reviews are scheduled for the first Monday of each Sprint for developed code from the previous Sprint and the second Monday for new code created during the current Sprint.

The Sprint iteration’s Tuesdays are available for code review scheduling issues and overrun when required.

The Daily Builds should have a code checking time requirement each day.

This is generally a 4:00 PM deadline for new code for the Daily Build and Smoke Test but can be anytime as long as it is constant time for the Developers to comply.

The Continuous Integration Manager for the current Sprint validates the Development Builds and code integrity through the Smoke Tests.

The Implementation of the Build Resolution Process

… Created by the Scrum Masters

…… Is the Responsibility of the CI Manager

Validated Integration Code is then pushed to the QA environment for QA testing and certification.

QA certified code is pushed to the production emulation Staging Environment for pre-production validation by the QA Team.

The second Thursday of each Sprint iteration is the delivery date of completed Business Acceptance Criteria production certified Staging Code.

There is a single Production Release in each Sprint. The Business Team is notified of the release details by the Product Owner.

The Product Owner receives the Release Notes from the Continuous Integration Manager.

The Quality Assurance Team consists of the following roles:

1. QA Manager
2. QA Lead
3. QA Test Analysts
4. QA Performance Analysts

The Sprint iteration consists of one or more QA Teams.

Not all of the roles listed above will be members of every team.

The responsibilities of some of the roles can be held by a single developer.

Only the QA Lead speaks during the Daily Stand Up meetings as the representative of the QA Team.

The QA Manager can speak if relevant information needs to be disseminated such as the current state of certified code and its readiness for migration to the preproduction Staging environment.

The QA Team certifies code that has been validated during the Integration phase of Development.

The Integration certified code complies with the QA Objectives that was initially defined during the Design Review and refined after the Development Review for use during the Integration stage of development.

The Integration Code Review certifies that the QA Objectives for the evaluated code base has been met.

The QA certified code base is now ready for the Continuous Integration Manager to migrate from Development environment to the QA environment for final Code Quality certification before moving the preproduction Staging environment.

The QA Representative is responsible for dissemination of this information to the Sprint Team.

The QA Teams supports the Business Team’s success criteria for the engagement.

The Primary responsibility of the QA Team is to support the Business Team’s success criteria for a given Business User Story.

The QA Team validates that the developed code meets the Acceptance Criteria of the Business User Story as defined by the Development Acceptance Criteria.

… QA Requirements are Initially Abstracted During the Design Review

…… Solidified during Code Review by the Developed Unit Testing Suite

… And Finalized as the QA Test Suite that is Delivered to the Development Team

…… For Use During Code Base Integration and Code Integration Review

The QA Test Suite for the developed code
that meets the Development Feature Story Acceptance Criteria
constitutes the QA Objective for the development Design.

IMPORTANT

The definition of success for the QA Team is NOT to find as many “Bugs” as possible.

The definition of success for the QA Team is to spend as little time as possible locating issues that should have been found by the Development Process.

The definition of success for the QA Team is to spend its time in exhaustive testing of a working code base to locate obscure issues before the Production release.

… The Concept of Giving the Developers the Test Suite

…… Is like Giving a Student the Answers to a Test

… Violates the Primary Responsibility of the QA Team

…… Efficient Use of QA Resources for the Business Team’s Success Criteria

The Network Infrastructure Team consists of the following roles:

1. Network Services Manager
2. Network Services Lead

The Sprint iteration consists of one Network Infrastructure Team.

This team is created to support the Physical Element of Software Development.

The team is a representation of the entire Corporate Infrastructure Entity.

It has a Network Services Manager and a single Network Services Lead at any given point.

The Network Services Lead is the Corporate Infrastructure’s representative for Network Services on the Sprint Team.

This Sprint Team member role can be a rotating responsibility and is managed by the Network Services Manager.

Network Services Manager is ultimately responsible for all products and service requirements for the Sprint iteration.

This role speaks during the Daily Stand Up meetings only when an issue is recognized.

A Network Infrastructure Domain issue raises a Development Block indicating that support from Corporate Infrastructure is required.

The Network Services Manager facilitates the removal of the Sprint blockage as quickly as possible through the Network Services Lead.

The Major Support Products and Services are:

1. Virtual Development Environment when required
2. All Operating Systems, Tools, Applications and Database Services 
   1. Development
   2. QA
   3. Continuous Integration
   4. Team Communications
   5. Sprint Management
   6. Document Management
   7. Knowledge Management
3. Performance Support
4. Hosting Services
5. Security Access including Firewalls and Gateways
6. Web Services and Endpoint Management
7. Cloud Services
   1. SAAS – Software as a Services services
   2. PAAS – Platforms as a Service services
   3. Data Repositories
8. Code Management
   1. Private Code Management Services
   2. Distributed Code Management Services

The daily availability of the required products and services are reported during that Daily Sprint Stand Up meetings to the Network Infrastructure Representative.

These reports create Sprint Blocks that are managed by the Network Infrastructure Manager for resolution as soon as possible.

The Daily Stand Up meeting is the heart and soul of the Scrum Sprint process.

The power of Agile is the “One Team” concept.

The ability to identify, discuss and set corrective action items as quickly is the major paradigm shift of Agile Methodology over the traditional Waterfall Methodology.

The Stand Up is named for the requirement that the meeting should last no more than fifteen minutes and should be a standing gathering so no one get “To Comfortable”.

There are two types of team members:

1. Speaking
2. Non-speaking

Each of the five Agile Teams is represented in every Daily Scrum Meeting:

The Business Team – The team members are the Scrum Master, Product Owner, Lexicon Master and a Business Representative for the Stakeholders and Subject Matter Experts. The Daily Stand Up members are the Business Representative, Scrum Master, Product Owner and Lexicon Master. The Business roles are non-speaking members. They speak when an issue is discussed that falls into their Business domain.

The Architect Team – The team members are the Architects and Designers. The Designers of the Sprint Backlog Items selected are the Team’s Representatives for the Daily Stand Up. The representative is a non-speaking member and speaks when an issue is discussed that falls into the Sprint Task Design domain.

The Development Team – The team members are the Development Lead, UI Developer, Application Developer, Back End Developer, Database Analysts, Business Intelligence Developer, the Continuous Integration Manage, Code Review Lead and the Code Technologists. All of the Development team is present for all Scrum meetings. All actively developing Development Team members speak with the following format:

1. What do you do yesterday?
2. What are you planning for today?
3. Do you have any blocks?

Any details about the blocks or planned or past activities are scheduled by the Scrum Master as on off-line follow-up meeting for resolution.

The QA Team – The team members are the QA Manager, QA Lead, QA Test Analysts and the QA Performance Analysts. A representative for the QA Team attends the Daily Scrum Stand Ups. The representative is a non-speaking member and speaks when an issue is discussed that falls into the QA domain.

The Network Infrastructure Team – The team members are the QA Manager and Network Services Lead. A representative for the Network Infrastructure Team attends the Daily Scrum Stand Ups. The representative is a non-speaking member and speaks when an issue is discussed that falls into the Network Infrastructure domain. 

What is the “Scrum of Scrums” Meeting?

When the engagement requires more than one Sprint Development Team there should always be a dedicated Scrum Master per team.

The Scrum Master Buffers the Developers from Distractions

… as Protection from Unnecessary Daily Issues Noise

…… Ensuring Productive Development Flows Unabated 

Each day after all the Daily Stand ups are completed all the team’s Scrum Masters meet for their own Daily Scrum meeting.

The meeting primary purpose is for creating a complete picture of the terrain of the engagement for the Scrum Masters.

The secondary purpose is to organize, schedule and execute the Block Resolution Meetings together to prevent duplication of effort.

Code Builds in modern development is also referred to as the “Continuous Integration Build”.

The power in the Agile Methodology lays in its ability to understand your development progress and lack of it as soon as possible.

The Daily Scrum Stand Up meetings act is a “Check and Balance” progress for Code Development.

The Continuous Integration Build acts as the “Check and Balance” process for Product Development.

… Tasks in Progress are Reported During the Stand Up

…… Code Completed is Validated During the Continuous Integration Build

The Continuous Integration Manager (CI) is responsible for the tool used for monitoring the Code Source Control System.

Continuous Testing

The Continuous Integration Build tool runs a rebuild on the code assemblies when changes are detected.

This is an automated process that ensures the stability of the entire code base.

The automated build tool also runs the Unit and Integration Test Suites that have been check-in by developers to validate that new code runs as defined by the developer who checked the new code into the Code Source Control System.

The Daily Build

Once a day the CI manager migrates, pushes the entire code base, to the Quality Assurance environment for QA Testing.

This action is taken only when the automated Continuous Integration Build process is successful.

… Once the Daily Deployment is Successfully Completed

…… The Daily Smoke Test Process is Triggered

The Daily Smoke Test is a series of high level validation of the major “Happy Path” tests.

The Happy Path are tests that only exercise the code’s ability to perform selected tasks when all environmental and application conditions are normal.

While the automated tests run during the Contentious Integration process will validate the core functionality, as defined by the developer who created the test suites, the smoke validates that the code runs as expected in the new QA environment.

Prior to smoke testing the new deployment to QA,
all developers that have new code in the Daily Continuous Integration Builds
must validate the code functions as expected

Smoke Tests are a Scripted based Application Validation Process

… That is Executed by the Continuous Integration Manager

Smoke testing is non-exhaustive testing.

Its purpose is to validate that most crucial functions of the code migrated works as expected.

The finer details will be exercised by the QA Team.

The Main Objective of the Daily Smoke Test

… Is to Certify the State of the Deployed Code to the QA Environment

…… For Exhausted Testing as Defined by the Developed QA Objectives

The focus of this process is a shallow but wide testing approach that delivers code to the QA team that passes the pre-QA testing process based on the QA Objectives criteria.

QA Objectives criteria, defined by QA during the Development process, is the Test Suite created to exercise the functionality based on the Business User Story Acceptance Criteria defined in the Design Statement of Work document.

The daily code development process is the implementation of the Sprint Task assignments defined during the Story Points to Task exercises and the commitment process of the “Right Sized” development efforts.

Code development is completed by Sprint Development Team members under a single, dedicated to the team Scrum Master.

There can be multiple Sprint Development Teams all with their own dedicated Scrum Master to manage the iteration development effort.

In order to help ensure that the integration of the developed code work properly each team should work on a well-defined bounded Domain Model that has been defined by the Business Domain using Domain Driven Design concepts.

The coupling between the two development arenas needs to be clearly defined, using the Ubiquitous Language, that supports seamless integration of team code bases.

The Daily Stand Up and the Scrum of Scrums meetings help to support this very important constraint.

Each developer should adopt a Daily Discipline Plan that includes the following activities as they are customized by the Client’s environment and development practices:

1. At the start of the development day, check the Daily Build Continuous Integration (CI) status of your code base to make sure that there are no issues regarding getting the latest code
2. Get the latest build code and compile if the Daily Build is certified as a successful build. Implement the Build Resolution Process if the build is broken.
3. Try to resolve all build issues, as much as possible, as the Daily Build and Smoke Test Continuous Integration process has deemed the code base valid. Most of the time any variance is due to changes in dependencies or missing new code from other developers that did not get to your Development Sandbox.
4. When an Atomic Code Block, code that is functional and testable as a single dependency, is completed check it in for CI validation. This makes your code available, as a planned defined dependency, for your team members as soon as possible. It also notifies you if you have integration issues within the development code base.
5. Make yourself available for quick communications with other developers via a Chat Tool. Keep the interaction time as short as possible to minimize distractions.
6. Check in all working code before the designated Daily Build Code Freeze Time. You should “Code Shelve” or “Code Stash” and code that is not fully functional before check-in and then retrieve it after the check-in is completed

IMPORTANT

Do Not End Your Development Day

… Until You Have Validated that the CI Build

…… Has Cleared Your Check-in from any Build Issues

The QA Testing process begins with the QA Lead and possible the QA Managers participation in the Design Review Process.

It is the responsibility of the QA Manager to make sure that the action item from the QA Team representative at the Design Review is an initial understanding of the QA Objective for that design.

The Design Review Action Item for the QA Lead

… An Abstraction of the Testing Requirements

…… for an Initial understanding of the Design QA Objective

The QA representative works with the other members of the QA Team to create the framework for the required Testing Suite that will be validated during the initial Code Review of the Design.

A QA Representative attends the Code Design Review for understanding of the delivered Test Suite and how it will help define the QA Objective for the developed code base.

The Code Review Action Item for the QA Lead

… A Refined Understanding of the Testing Requirements

…… for Developing the Finalized QA Objective

The QA Lead works with the QA representative and the QA Team members to complete the finalized QA Objective test suite.

The QA Objective Test Suite is delivered to the Development Team for use in validating that the Code Integration process meets the Business Teams success criteria before the Integration Code Review.

The Code Integration Review Action Item for the QA Lead

… A Confirmation of the Validity of the Finalized QA Objective

…… for Updating, if Required, the Finalized QA Objective

The role of QA representative during the Design and Code Reviews is a delegated assignment by the QA Lead or the QA Manager.

IMPORTANT

The most important factor in Daily QA Activities is that
the QA Team and the Development Team are always
“On the Same Side of the Volleyball Net”
and are not playing against each other

By far the most important process of the Development Sprint Iteration is the Code Design and Code Review process.

The Return on Investment of Successful Implementation

… Of the Design and Review Process

…… Can Have Exponential Results

Quality Assurance is extremely expense. It is also extremely important.

If the paradigm for QA is “Us Against Them” between the Developers and the QA Testing team creating a “Gotcha” environment then the Client is paying for activities that serve no value to the Business Team’s User Story Acceptance Criteria.

This additional cost can run three or four times and even over ten times the cost of replacing that paradigm with the paradigm defined by TMD Sprint Development Process.

A Sprint Iteration creates iteration development requirement by creating Sprint Tasks from User Story Points.

These tasks can be designed by Architects and Developers due to the Design Review Process.

The implementation of a Formal Design Review process of all code design road maps fosters the cost savings of delegating the initial design requirements to the lowest competent developer skill set.

Rather than requiring skills that may not be needed by an Architect Designer, the Architect Team’s Designers can delegate some design responsibilities to the Development Team when it is believed that the Development Team member has the required skills to create a competent design for discussion during the Design Review of the designated Sprint Task.

The Design Delegation Process
requires a good understanding the
Development Teams member skill sets

The proposed Coding Design is documented using the Statement Of Work Design template.

The Design Review certifies the Design abstraction concept presented in the SOW and commissions it for development.

The SOW is the criteria the QA Team representative delivers to the QA Team as the initial QA development requirements for the QA Objective.

QA Objective is the requirements for meeting the Business Team’s Acceptance Criteria.

There are two Code Review Sessions per Design.

1. Development Code Review – This session validates that Test Driven Development (TDD) has produced a viable automated test suite that supports the Design requirements as defined by the Design Certification Statement of Work (SOW) document.

The review ensures that all dependencies, that are not part of the SOW design requirements, have been created as either “Mocked Objects” or “Stubbed Out Objects”.

It is important to make sure that the tests are true Unit Tests, single unit of work tests, and not Integration tests.

The tests need to validate all Tested Method Object result’s will pass “Today, Tomorrow, Next Week, Next Month and Next Year” with explicit values that cannot change over time.

The QA Team uses this session to gain the knowledge required for finalizing the QA Objective.

2. Integration Development Code Review – This session validated the replacement of the Unit Tests with Integration Tests.

The Unit Tests are copied and the Mock Objects are replaced with their System Dependencies.

The old Unit Tests are decorated with an [IGNORE} attribute for automated test run performance.

They are moved into a Unit Test code region to encapsulate the Archived Tests to reduce Code noise for better readability.

These Unit Tests are reactivated when required for bug fixes and new feature / functionality requests.

The QA Team delivers to the Integration Developer the finalized QA Objective for the Road Map for integration into the developed system.

The Integration Review validates the QA Objective and certifies that the developed code base meets the Business Team’s acceptance criteria.

The preeminent objective of the Code Review process is to deliver to the QA Team developed code that has been pre-tested for compliance with the Business Team’s Success Criteria.

This objective creates an environment where the QA Team can efficiently concentrate on finding issues that the developers had not thought of during the development activities.

IMPORTANT

The definition of success for the QA Team is NOT to find as many “Bugs” as possible.

The definition of success for the QA Team is to spend as little time as possible locating issues that should have been found by the Development Process.

The definition of success for the QA Team is to spend its time in exhaustive testing of a working code base to locate obscure issues before the Production release.

… The Concept of Giving the Developers the Test Suite

…… Is like Giving a Student the Answers to a Test

… Violates the Primary Responsibility of the QA Team

…… Efficient Use of QA Resources for the Business Team’s Success Criteria

The TMD Sprint Measures complies with the TMD Team Wisdom Pearl #103:

Managing Technology Results

If You Can’t Measure It

… You Can’t Manage It

…… Always Create Ways to Quantify Your Results

There are three primary measures defined in the Agile Methodology:

1. Sprint Velocity – This measure tracks the number of Story Points completed within a Sprint Iteration. It maps the Sprint Development Teams “Defined Development Efforts” to the Business Team’s User Stories defined “Domain Feature Requests”.

2. Sprint Increment – This measure tracks the number of Tasks completed within a Sprint Iteration. The difference between Velocity and Increment is real-time Development. Mid-Sprint Task re-assessment and iteration “Scope Creep” will add development tasks to the Sprint without changing the Story Points. The Increment measure tracks these “Development Efforts”.  

3. Sprint Burn – This measure tracks Sprint Scope versus Iteration Duration. This can be seen as a Burn-Up or a Burn-Down display. The most accurate for understanding the true activities of a Sprint is the Burn-up view. The Agile Series post “The Sprint Velocity, Increment and Burn Metrics” details the difference between the Burn-up and Burn-down metric.

The real engagement value of the Sprint Metrics
is the ability to use the results of a Sprint
to make the adjustments required to improve
the Sprint Teams throughout the entire
Business Development Life Cycle of the engagement.

The total effort a team is capable of in a sprint.

The number is derived by evaluating the work, in story points, completed from the last sprint’s backlog items.

The collection of historical velocity data is a guideline for assisting the team in understanding how much work they can do in a future sprint.

The Business Team defines the changes to the Business Domain through a collection of Business User Stories.

These User Stories are massaged and placed into the Product Backlog for future consideration for Sprint iteration development.

Not all User Stories make it to a Sprint.

The Sprint Metric that tracks all of the Backlog Items that are completed during the engagement is the “Increment” Metric.

When a Backlog item is certified completed according the Scrum Master’s “Definition of Done” (DoD), at end of a Sprint Iteration, it is added to the Agile Increment count.

The Sprint Burn can be a Burn-up or Burn-down or both.

Sprint Burn Up – Burn-up chart’s mechanics is basically the same as the Sprint Burn-down. The only difference is that instead of tracking how much work is left to be done, we track how much work that has been completed, so the curve is going up, not down.

Sprint Burn-down – It is a simple graph showing amount of work on a vertical and timeline on a horizontal axis. As time progresses the team tracks how much work is still not done. The goal is to hit the ground. The steepness of the curve can help approximate when it’s going to happen or, in other words, when we’re going to be done with the all of the assigned work.

The Agile Series post “The Sprint Velocity, Increment and Burn Metrics” details the difference between the Burn-up and Burn-down metric.