2. Agile Reporting: Velocity
Velocity is one of the most misunderstood
concepts involved with Agile.
Velocity is a team measure that is used to
determine how many stories can be taken off the
Product Backlog into any specific Sprint Backlog.
Past Velocity achieved is used by the team to
guide themselves in making commitments to the
work to be done in a Sprint Planning session.
Thursday, July 4, 13
3. Agile Reporting: Velocity
Velocity should not be used to measure one
team’s productivity verses another because the
story point assigned are subjective.
There are many differing views on whether story
points should be story hours or days.
SAFe uses a standard and objective measure of
velocity based on number of team members and
the duration of the Sprint.
Thursday, July 4, 13
4. Credit For SAFe
The following three slides have images from
www.scaledagileframework.com
The Scaled Agile Framwork is the work of Dean
Leffingwell and Scaled Agile, Inc. owns the
copyright to these images.
Please see www.scaledagileframework.com form
more information.
Thursday, July 4, 13
5. Agile Reporting: Velocity
In SAFe all Sprint Teams have a computed
Velocity and stories are scheduled by the team
through a capacity allocation technique.
Thursday, July 4, 13
8. Agile Reporting: Velocity
There are two ways teams determine story points:
Planning Poker or Affinity Planning
Thursday, July 4, 13
9. Agile Reporting: Velocity
Velocity may also be used to make projections at a
high level, and to allow teams to measure its
improvement against itself NOT OTHER TEAMS!
Thursday, July 4, 13
10. Agile Reporting: Defects
Quality Assurance is continuous and testing is part of
programming.
Functional defects should break the build and never
enter production.
Thursday, July 4, 13
11. Agile Reporting: Defects
Sprint and PSI Demo’s (Reviews) should include the
stakeholders needed to ensure that code meets the
intended requirement.
Thursday, July 4, 13
12. Agile Reporting: Defects
For Customer Delight to be achieved, developers
need to be enabled to know how to exceed
expectations. The Product Owner is a Customer
Proxy. Definition of Done should include metrics
that measure Customer Delight.
Thursday, July 4, 13
13. Agile Reporting: Defects
Feedback loops and automated means of measuring
software adherence to specification is key to
Customer Delight.
Thursday, July 4, 13
14. Agile Reporting: Defects
Don’t forget “Business Delight”
Business stakeholders should ensure that assumptions
made regarding Return on Investment are used as
metrics of performance for software delivered.
Thursday, July 4, 13
16. Agile Reporting: Governance
If teams are measured by outcomes instead of
outputs then completion of development is merely a
means to an end.
Teams should be enabled to address governance
issues and the Scrum Master must be empowered to
remove them as impediments or blockers.
Thursday, July 4, 13
17. Agile Reporting:
Organizational Readiness
If the software being developed has to be finished to
begin development of Standard Operating
Procedures (SOP’s) then deployment will be
unnecessarily delayed.
The true life-cycle of development includes
Organizational Readiness.
Thursday, July 4, 13
18. Agile Reporting:
Organizational Readiness
Collaborative processes in development may be
extended to include deployment issues and
Organizational Readiness, when integrated into
development life-cycles they will often yield learnings
that foster better innovation and outcomes.
Thursday, July 4, 13
19. Agile Reporting:
Continuous Deployment
Effective collaboration with deployment-related
stakeholders may foster the ability to automate most
deployment tasks and further increase speed-to-
market.
Agility is an organizational issue and speeding
development will only solve part of the problem.
Thursday, July 4, 13
20. Agile Reporting:
Continuous Deployment
Effective collaboration with deployment-related stakeholders
may foster the ability to automate most deployment tasks and
further increase speed-to-market.
Agility is an organizational issue and speeding development
will only solve part of the problem.
Organizations that wish to benefit from fast and frequent
releases must automate Continuous Deployment in addition
to strict disciplines of Continuous Integration.
Thursday, July 4, 13