The Agile End Game: Product Release
All of these activities:
Business Team Meetings
Architect Team Design Sessions
Development Team’s Daily Stand Up Meetings
QA Team Activities
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“:
Unlimited Time | Flexible Features – This is the preferred situation and most likely NOT to be a choice the modern business environment
Limited Time | Flexible Features – This is the situation that will ultimately be reality in most situations for a fixed Software Product release schedule
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:
All Business Stakeholders Features expectations for the release, or releases, are understood and represented within the Agile Product Backlog
The Business User Story Features are verified by the Stakeholders for the correct understanding of the development requirements by the Agile Teams
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.
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.
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
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:
Sprint Begin Date – Calculated Value from First Sprint Date
Sprint Iteration Number – Calculated Value from First Sprint
Backlog Size: Sprint Start – Entered Value that Represents the Initial Estimated Product Backlog Points then Calculated Value from First Sprint Metrics
Sprint Backlog Committed – Entered Value that Represents the Estimated Team Velocity for a Given Sprint: How Many Points will be Completed that Iteration
Sprint Backlog Completed– Entered Value that Represents the Actual Velocity Value from the Completed Sprint
Team Velocity – Calculated Value from the Velocity of the Current Sprint
Backlog Items Added – Entered Value that Represents the New Items Added to the Product Backlog
Backlog Bug Items Added – Entered Value that Represents the New Bugs Added to the Product Backlog from the Last Iteration
Backlog Items Removed – Entered Value that Represents the Backlog Items No Longer Required Due to Changes in Scope or Completed in Other Backlog Items
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
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.
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
The following two tabs change content below.
I am a Principal Architect at Liquid Hub in the Philadelphia area specializing in Agile Practices as a Certified Scrum Master (CSM). I use Test Driven Development (TDD) and Acceptance Test Driven Development (ATDD) with Behavior Driven Development (BDD) as my bridge to Agile User Stories Acceptance Criteria in a Domain Driven Design (DDD) implementing true RESTful services