Traditionally, projects are managed based on cost, schedule, and scope. This has lead to poor outcomes, unsustainable development efforts, quality issues, and less than ideal software in terms of value to its users. Our talk will go into how organizations can integrate quality and value considerations into their portfolio management strategies to have a more holistic view leading to less surprises and more valuable outcomes. The talk will go into detail about how Agile plus traditional Earned Value Management (EVM) alongside Managing Software Debt can give a more holistic view of the project portfolio.

1. Integrating Quality into Portfolio Management
Brent Barton
Chris Sterling

2. Brent Barton - Sterling Barton, LLC
Partner, Sterling Barton, LLC
Former CTO. Active Agile Coach, Mentor, Certified Scrum
Trainer
More than 15 years software development in many roles as
both employee and consultant for organizations from small
start ups to multinational corporations
Actively involved in Agile Rollouts from small Product
companies to very large IT organizations
Scrum Articles
Email: brent@sterlingbarton.com
“AgileEVM – Earned Value Management Web: www.sterlingbarton.com
in Scrum Projects”, IEEE Blog: gettingagile.com
Follow me on Twitter: brentbarton
“Implementing a Professional Services
Organization Using Type C Scrum”, IEEE
“Establishing and Maintaining Top to
Bottom Transparency Using
the Meta-Scrum”, AgileJournal
“All-Out Organizational Scrum as an
Innovation Value Chain”, IEEE
© 2009-2010, 2

3. Chris Sterling – Sterling Barton, LLC
Partner, Sterling Barton, LLC
Consults on software technology, Agile technical
practices, Scrum, and effective management
techniques
Certified Scrum Trainer
Innovation Games® Trained Facilitator
Open Source Developer
Software architecture consulting for Agile Teams: Email: chris@sterlingbarton.com
Web: http://www.sterlingbarton.com
Continuous Integration Blog: http://www.gettingagile.com
Follow me on Twitter: @csterwa
Source Code Monitoring
Release Management
Design techniques
© 2009-2010, 3

4. Meet Earl -
Strategic Planner
Earl just finished the annual
portfolio budgeting process for
the new fiscal year
© 2009-2010,

5. Meet Geoff -
“Project Manager”
Geoff was a Software
Developer
and is now in charge of Saturn
Saturn is a key part of a
company-wide strategy
© 2009-2010,

6. Portfolio is Done for the year! (Today is the
beginning of our new Fiscal Year)
© 2009-2010,

7. Later, Some things aren’t looking as good
© 2009-2010,

8. [Pause for enlightening discussion]
© 2009-2010,

9. Defect Containment is helping...not solving
© 2009-2010,

10. So...what is happening? Who is affected?
© 2009-2010,

11. Continuous Integration
© 2009-2010,

12. Meet Huang -
Test Engineer
Huang is a Software
Development Engineer in Test
- SDET
Huang wants to proud of the
quality of every release
How can I help?
© 2009-2010,

13. © 2009-2010,

14. [Pause for enlightening discussion]
© 2009-2010,

15. Meet Earl -
Strategic Planner
How do I balance
Value and Quality?
© 2009-2010,

16. Balancing Signal Indicators
- (some weaker than others)
Value
Quality Constraints
(Schedule, Cost, Scope)
© 2009-2010, Source: Jim Highsmith

17. [Pause for enlightening discussion]
© 2009-2010,

18. Meet Sonia -
Program Manager
Sonia is a Program Manager
Uses Scrum well...good
servant leader
How can I help
ensure better
Quality?
© 2009-2010,

19. Definition of Done
Defines the work products that will
be delivered with each item as it is
ready for acceptance
Typical entries in Definition of Done
Code includes unit tests,
reviewed, checked in
Tests described and executed
Build, release notes
Compliance documentation
updated to include current
functionality
What else?
© 2009-2010, 19

20. Definition of Done as a Compliance Checklist
Acceptance defined criteria for each Code checked in with reference to
user story US#/Task#
Unit tests written and passed Tested on FE
Code compiles with no errors and no Integration test written & passes
warnings
Test code reviewed
New code doesn’t break existing code
Environment requirements documented
Test case review (Dev to review test
Interface document updated/added
case written)
and checked in to SVN
Architectural impact assessed and
Acceptance criteria verified complete
artifacts updated if necessary
All P1-P3 bugs for the story are
Comments in code
closed
Error codes added
Test approves user story
Code reviewed by peer
Story demonstrated to product owner
and accepted on Target Platform
© 2009-2010,

21. How does a “Release Definition of Done” help?
Every release should have clear quality criteria
With a “Release Definition of Done” you can understand targets better
Measure the gap between the teams’ Definition of Done and a Release
Definition of Done.
This gap is a source of quality issues and represents significant risk to
schedule
© 2009-2010,

22. [Pause for enlightening discussion]
© 2009-2010,

23. I think we’re “done”
© 2009-2010,