The Agile End Game: Product Release

All of these activities:

1. Business Team Meetings

2. Architect Team Design Sessions

3. Development Team’s Daily Stand Up Meetings

4. Design, Development and Integration Code Review Process

5. QA Team Activities

6. Network Infrastructure Team Support

are all for one focused goal:
Development Product Release

The major reason that the Agile Development approach works so well is the paradigm shift from focusing on managing the “Project” to managing the “Product“.

The development and delivery of a quality software product, by “Dropping Code” any way possible, is the only thing that matters in Agile development methodologies.

Manifesto for Agile Software Development

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

Step One: The Software Product Backlog

Here are the three primary development release constraints. Time reflects money as “Time is Money“:

1. Unlimited Time | Flexible Features – This is the preferred situation and most likely NOT to be a choice the modern business environment

2. Limited Time | Flexible Features – This is the situation that will ultimately be reality in most situations for a fixed Software Product release schedule

3. Limited Time | Fixed Features – This is the situation that management will try to enforce and will have to be mitigated through understanding of the reality of Software Development constraints. This is not an easy task sometimes when moving from Waterfall to Agile

The complete list of Development Features that the Software Product requires creates the Product Backlog.

These items are created by the Business Stakeholders as Business User Stories and groomed by the Business Analysts (BA) and Product Owner (PO).

User Stories are Owned by the Product Owner

Each of the User Stories is prioritized based on the Stakeholders belief of the level of importance to the company’s future competitiveness in their markets.

Step Two: Estimating the Product Backlog

The Software User Stories Features are assigned a “Level of Estimated Effort for Completion”.

Sometimes Business Stakeholders and Subject Matter Experts will evaluated Software User Stories Features as “Levels of Complexity” and if that helps to understand “Estimated Effort” then that is OK.

This is just a guess of the relationship of perceived effort required based on other User Stories in the Backlog.

Software User Story Features are generally called Epic Stories that contain smaller Epics and Child Stories that can be estimated for relative levels of development effort

Software User Story Features Points are generally these numbers: 13, 20, 40, 100, Infinity (∞) and Unknown.

It is based on some known requirement that is used as a base reference.

This is generally a Software User Story Feature Epic feature of “40”.

All other Story Point Features are set at a level higher or lower that reference.

I am not a big fan of “T-Shirt Sizing” for Sprint Tasks as the sizes are not additive by using their sizes. We can assign values to the sizes that reflect the Epic levels to get a vision of relativity.

In Business User Stories, however, it is sometimes easier to visualize the scope of an Epic and Child Epics as “Sizes” that can be related to each other.

… Do Not Feel that You Need to Be Perfect

…… Agile is Based on Knowledge Now

The Epics need to be decomposed into Business User Stories that have Story Points that be visualized as Development Tasks within a Sprint iteration.

This process creates Story Points that range from 0 to 13 in increments of: 0, 1, 1.5, 2, 3, 5, 8 and 13 points

Any Decomposed Epic User Story

… That is Greater than 13 Points

…… Needs to be Reassessed

After all the Product Backlog Epics have been created as decomposed Epics and Child Epics into Development User Stories they add summed to create the Total Software Release Backlog Story Points.

Step Three: Grooming the Product Backlog

Fine-tuning the Product Backlog for Sprint Estimations requires a “Groomed” Product Backlog.

The Product Backlog must be reviewed by the Product Owner(s) at the end of each Sprint after the initial grooming before Sprint One.

This is to ensure that change requirements gained by knowledge from the iteration have not affected priority and value of any User Story.

Requirements for a well-groomed Product Backlog:

1. All Business Stakeholders Features expectations for the release, or releases, are understood and represented within the Agile Product Backlog

2. The Business User Story Features are verified by the Stakeholders for the correct understanding of the development requirements by the Agile Teams

3. All Features, as Epics and Child Epics, are estimated in Story Points with all known constraints and requirements to the best of all Agile Team members at this time.

4. All Feature Stories have a priority assigned and the priorities have been reviewed and finalized by the Business Stakeholders, Subject Matter Experts, the Business Analysts and the Product Owner.

5. A Minimum Viable Feature List has been defined as the absolute minimum features required for the first release

When the requirements are accepted and understood by all the Agile Team Members then the Backlog is ready for the Release Planning stage

Step Four: The Product Release Planning

We can create an initial timeline based on the estimated completion of the Feature Story Points.

This will act as a “High Level” plan, a feasibility plan.

This estimation will be replaces with real-time Sprint Story Points completed statistics, known as the  Sprint Velocity, as the development iterations actually are completed.

The Release Plan Worksheet

With a well-groomed Product Backlog we are ready to do some “Release Planning Projections”.

We will create a set of estimations that are based on historical statistics that represent the natural learning curve of Agile.

The statistics we will be working with are listed below:

1. Sprint Begin Date – Calculated Value from First Sprint Date

2. Sprint Iteration Number – Calculated Value from First Sprint

3. Backlog Size: Sprint Start – Entered Value that Represents the Initial Estimated Product Backlog Points then Calculated Value from First Sprint Metrics

4. Sprint Backlog Committed – Entered Value that Represents the Estimated Team Velocity for a Given Sprint: How Many Points will be Completed that Iteration

5. Sprint Backlog Completed– Entered Value that Represents the Actual Velocity Value from the Completed  Sprint

6. Team Velocity – Calculated Value from the Velocity of the Current Sprint

7. Backlog Items Added – Entered Value that Represents the New Items Added to the Product Backlog

8. Backlog Bug Items Added – Entered Value that Represents the New Bugs Added to the Product Backlog from the Last Iteration

9. Backlog Items Removed  – Entered Value that Represents the Backlog Items No Longer Required Due to Changes in Scope or Completed in Other Backlog Items

10. Sprint Estimation to Completion – Calculated Value Including All Metrics Constraints above. This is the Non-Weighted Completion Estimate of the Number of Required Sprints at the Current Velocity Rate

11. New Bugs / Rework – Allocation % – Calculated Value of Unknown Forces that could cause Additional Sprint Effort. This is a Historical “Headroom” percentage that is applied after the First Sprint. It is generally a 5% starting and increasing to about 25% at the 7th – 8th Sprint and then Decreasing. The last four Sprints may see increases due to a final surge of Release Scope.  

12. Weighted Sprints to Completion – Calculated Value of the True Number Of Required Sprints based on the Weighted Values

A Sprint Planning Worksheet is an automated spreadsheet that allows the Release Planner to create “What If” scenarios.

Estimated Sprint Backlog Commitments and Completed Velocities can be entered and projected out to a defined Release Date and beyond.

The planner can guess at new Backlog Items that could be added after each Sprint along with Bugs and Items Removed to see the effect of changes in the scope as more knowledge is gained.  

The Allocation percentage can be adjusted to view the effect of the “Unknown” on the Release date estimation.

The Estimated Values are Replaced by Actual Values at the End of Each Sprint

The Modern Developer’s Release Planning Worksheet:

You can download the Release Planning Estimation Excel worksheet from the link from the image below:

In Conclusion …

The primary reason that Agile is effective is that the only thing that matters is Product Release.

Keeping your “Eye on the Ball” and not letting the “Business Noise” around you will help you be successful in environments that may be resisting the change to an Agile Methodology.

The Product Release Planning Process helps the Stakeholders understand the Agile Sprint Process for getting the “Biggest Bang for their Buck“

Never Let the “Process Noise” Distract You

… Well Developed and Well Tested Product

…… Will Trump all “Process Noise” Every Time

Wisdom Pearl # 139 – What is World Class

Seeking World Class is a Journey

… Not a Destination

…… Ensure You are on Your Path to being World Class Every Day