Nicholas Del Carlo, of OD Management, discusses Release Burndown and Burnup Metrics

Share Article

When trying to implement good Scrum and Scaling good Scrum across and organization during an agile tranformation it is the Product Owner that owns Product Release Metrics and or Release Burndown. Source: Nicholas Del Carlo, Agile Coach and Scrum Professional at OD Management

Release Burnup example

Your organization should make sure a team succeeds with the basics of Scrum training before enacting an agile transformation of scaling Scrum across multiple teams in the organization.

While Ray was working with several clients attempting to transition large scale enterprise to a more Agile enterprise, he noticed a few incorrect processes. For example, he noticed companies assigning the release burnup or burndown metrics to the Scrum Master to manage and own. The organization feels that since the Scrum Master manages the Sprint burndown, he or she should obviously manage the release burnup or burndown and own it. This is a common misnomer among organizations with application development and or product creation. Yes, the Scrum Master owns and manages the burndown since it’s a radiator creating visibility to the team on progress and velocity. But the one person who should own the release burndown or burnup is the Product Owner not the Scrum Master.

The Product Owner owns the priority of features to be created per customer needs. During this process the Product Owner will often change their mind and priorities will shift. Hence, he or she as a PO will take an item or two out and replace it with a more current need. This fluctuation is in sync with the priority of features in the release. The Scrum Master can help the Product Owner with the release metrics, but the Product Owner owns the Release metrics and oversees showing it to their customers on a needed basis. This depends on the wants and needs of metrics and or analytics of their product being built.

Your organization should make sure a team succeeds with the basics of Scrum training before scaling across multiple teams in the organization. This will ensure that good scrum and high performing work efficiency will scale with the organization. If the organization decides to cut corners and slap Scrum on top of Waterfall projects, then what they are scaling will end up being mediocre and create more correction problems down the road.

In retrospective we want to make sure everyone is following good Scrum and adhering roles within the scrum team. Now more than ever it is important to ensure everyone is following a good process and tries to incorporate Kaizen with small improvements every sprint if possible.

Organizations want to encourage teams to release a minimal viable product or increment at the end of every sprint until they get mature enough to release during the sprint with automating test-driven development “TDD”. Automating testing will help increase the team’s speed of product to market and increase your team’s velocity across the organization.

Share article on social media or email:

View article via:

Pdf Print

Contact Author

Nicholas Del Carlo, M.S.
since: 08/2009
Follow >
ODM E-Learning Development, LMS and Authoring
Like >
Follow us on
Visit website