1. Envisioning - Improving Productivity and
Quality through Better Backlogs
Keynote
Agile Portugal 2010
Dave Thomas
dave@bedarra.com
Bedarra Research Labs, Object Mentor
Carleton University Canada, Queensland University of
Technology Australia
©2010 Bedarra Research Labs. All rights reserved.
Outline
We love Agile but ....
It’s ALL in your Backlogs!
Why Envision?
Lean and Agile In The Large
Envisioning in Practice
Flow
Team and Roles
Practices
Q&A
©2009 Bedarra Research Labs. All rights reserved.

2. We love Agile Development BUT ...
There are really just a couple of problems
Productivity
Quality
Predictability/Estimates
Re
Te
Management of Expectations
qu
st
Product Owners Availability
ire
in
g?
m
Reduce Owner Burnout
en
!
Requirements Churn
ts
?!
Portfolio Management
Reduce Rework
Reduce Integration Costs
Not Collocated
....
©2009 Bedarra Research Labs. All rights reserved.
Predictability, Quality, Productivity, Agility and Value
Agility
Value
Productivity
Needs 5 – 15%
Predictability
Agile
Surveys show Scrum
Scrum increases morale and
productivity, but only
TDD TDD impacts quality
Quality
©2004 Bedarra Research Labs. All rights reserved.

3. It’s All in Backlogs! Evidence for Action
Lumpy Stories – sizes, estimates, clarity
Story Rework Due To Changing Requirements
Uncompleted Stories
Story Rework Due to Integration Problems
Missing Important Functionality
Done but not usable, poor performance
Done doesn’t mean acceptance tested?
More stories keep getting added to the backlog
Lack of business Value/Tangibility
Blocked on Another Team
Blocked waiting on Product Owner
All resources 100% + allocated
©2009 Bedarra Research Labs. All rights reserved.
The Fundamental Problem - Requirements
67% of all projects failed, late, over budget, or under featured.
35% of those projects identified lack of user input, incomplete
requirements, and changing requirements as the problem.
?
What the user What the developer
thinks he’s getting… thinks he’s delivering…
Source: Standish Group. Chaos Reports. Challenged Projects

4. Too Many Requirements versus Too Few
The Waterfall Pitfall
Plan ‘everything’ before you do ‘anything’ until…
It’s 2 years late, 173% over budget, kinda
buggy, & costs $32,345.99…
But “it does everything you’d ever want to do!”
The ‘Potential’ Agile Pitfall
“Planning, shmanning, I need to add 1+1, so let’s just
build it!” On time, on budget, and we’re giving it
away as a beta. “It’s bug-free, it works, and it adds
1+1!” Darn… now how do we add all the features
we never had time to think about?
Envisioning gives Agile some breathing room…
Allows us to understand enough of the vision of ‘tomorrow’…
Top 10 Things To Succeed in a Large Transition
1. Lean and Agile Assessment
2. Establish Realistic Expectations for Predictability, Quality and
Productivity
3. Plan for Systemic Change
4. Establish a Change Management Plan – Role/Job Changes, Governance,
Transition Team, Communications …
5. Implement the CI Infrastructure
6. Implement the Automated Measurement Infrastructure
7. Decouple Legacy Code
8. Implement a Lean Organization Structure with a Strong Technical
Ladder
9. Implement the Feature and Component /Platform Team Structure
10. Use Experienced Trainers and Coaches – Technical, People,
Management
Need Systemic Organizational Change 18 – 36 months

5. Large Scale - Social Engineering
Common Culture
Values and Vision
Common Vocabulary, Practices, Tools
Common Tools and Global Transparency
Empower Distributed Teams – Skype, Live Boards, Developers Travel
Directing transitions to Coaching and Mentoring
Use Playing Coaches to share vision and experiences
DONE Means Test – Our Code Doesn’t Smell
Align Individual/Team Compensation with Desired Behavior
• Predictable Delivery
• Quality Delivery
• Teamwork
• Early Problem Identification and Resolution
Playing Coaches, Technical Ladders and Communities
Executive
Technical Leadership Council
Distinguished
Engineer
Technical Director
Senior Member
Technical Staff
Individual
Team Leader Contributor… Outstanding
Contributor
Individual
Management
Contributors… Customer
Product Architects
Mgr Leads
Communities of Release Products Tools
Process
Practice Deployment
Infrastructure
Support
Platforms
Test
Coaches
Driven
Development

6. Lean and Agile In The Large (AIL)
Participation of whole team in entire life cycle
A simple common language from portfolio management to
release engineering
Ensures well formed development backlogs by iterating on
items to ensure requirements are tangible hence testable.
Concurrent and artifact driven allowing teams to increase
through put and reduce blocking
Teams own their own quality, predictability and transparency
Provides coordination across multiple feature and component
teams
Enables the business to make long term commitments with
known risk
Comprehensive automated measurements provide complete
transparency
Large-Scale AIL Development Activities At-A-Glance
Lean and Agile Values and Principles
Product Owner Team Common Work Practices
Envisioning Definition Development Release
Engineering
Team… Team… Team…
Team…
CI&T
Prototypes/Models Architecture
Requirements Product Backlog Team Sprint Shippable
Backlog Release Release Code CI&T
Backlog Backlogs Increments
Risk Backlog
Team… Potentially
Shippable
Product
Release Backlogs
Team…
GUI Guidelines
©2006-2007 Bedarra Research Labs and Object Mentor

7. Common Work Practices and Rhythms
Regardless of the activity, each team is self managed through the
use of four key practices
Backlogs Sprints Continuous Metrics
Used to Organize Used to Execute Integration (CI) Used to Track
The Work By The Work In Used to Ensure and Maintain
Value Small Increments Quality Visibility
Sprint (Iteration) Rhythm (2 wk) numbered by start week of year e.g. 01-09,
03-09 ….
§ Sprint Planning , Daily Stand-ups .., Sprint Retrospective
Development Rhythm
§ Design Acceptance Test, Design Unit Test, Design Code, Build and
Test
Feature Release Rhythm numbered by start week of year 06-09 or 08-09 ….
§ 3 - 6 sprints per feature release
Metrics – You Can Only Improve What You Can
Measure
Artifact
Status Reporting
Status of artifacts such as
personas, problems, use
scenarios, stories
Burndownc harts
CI Environment
Reporting
Status of stories written, Query &
stories completed, tests Reporting
written, tests passed and
tests failed Engine
Unit and Story Tests
Subjective
Reporting
Qualitative data entered by
Scrum Masters after every
sprint regarding sprint
progress and issues
Retrospective Reports

8. Artefact Flow
Enable Large Customer Commitments
Leverage Architecture and
Ensure Good Backlogs Components
Sprint When Ready Ensure Transparency
Envisioning
Customer
Needs,
Definition
Wants,
Desires
Development End Game
AIL Portfolio (Backlogs)
Portfolio Program Feature Team
Company Backlog
P1 F1 Blue
F2 Blue
Program Backlogs
F3 Red Team Backlogs
F4 Red
F5 Red
F6 Red
P2 F7 Yellow
F8 Green
F9 Green
F10 Purple
F11 Purple
P3 F12 White
F13 White
F14 White
F15 White
Component F16 Orange
F17 Orange
F18 Orange

9. AIL Feature Story Decomposition
Program Medical Imaging
Feature MRI Mechanical Control System
Epic Table Movement
Story Horizontal Table Movement
Task Position Table w/ Joy Sticks and Dials
Tangible Requirements
• easily expressed by Business
• easily understood by developers/testers
• acceptance easily understood by Business
• acceptance easily understood by IT
• acceptance criteria (AC) => acceptance test (AT)
Acceptance
Story Criteria
©2004 Bedarra Research Labs. All rights reserved.

10. Acceptance Criteria
Acceptance criteria must be tangible and measurable
Developer needs to be able to write an acceptance test
based on the acceptance criteria.
Tests against feature, epic and user story
Basic categories of acceptance criteria
§ Format (e.g. UI must be section 508 compliant)
§ Functionality (e.g. Flight cancellations must be performed manually)
§ Reliability (e.g. 99.999% uptime)
§ Performance (e.g. screen loads within 5 seconds, list loads 500 records
in 10 secs, visual feedback on item selection occurs in less than 200 ms)
§ Capacity (e.g. 100 concurrent transactions, 1000 transactions per
second)
§ Security (e.g. web audit trail of all transactions)
Development ramifications of acceptance criteria
§ Tracking of detailed web interactions means need to store 10TB per
month
§ Manual flight cancellation impacts system performance
§ 99.999% uptime means redundant system architectures and hot
swapping
§ Slow visual feedback means examination of frameworks for performance
issues
AIL Artifact Break Down
Program is a collection of Features (annual plan updated quarterly)
Feature Release (Quarterly) described by Feature Stories
Large Features( >3 months) broken up into visible feature releases
Every Feature has a set of Acceptance Criteria and Acceptance Tests
Features are composed of Epic Stories
§ An Epic must be completed in a single release
§ An Epic cannot span a team
§ Work that needs to be completed by another team
(component/feature team) is placed in a separate Epic
§ Every Epic has a set of Acceptance Criteria and Acceptance Tests
§ Epics are composed of Stories
§ A Story must be completed in a single Sprint
§ A Story which is larger is broken into multiple Stories
§ Every Story has a set of Acceptance Criteria and Acceptance Tests
§ A Story is often broken down into Tasks
– Tasks have a duration of 1 – 2 days and are normally
– completed by a single person

11. DONE = Acceptance Tested!
A Story is DONE when its Story ATs pass
An Epic is DONE when all its Story ATs pass
A Component is DONE when all its Epic (API/Service Level) ATs pass
A Feature is DONE when all its Epic ATs pass
A Program is DONE when all its Feature ATs pass
AIL Feature Planning Flow
Envisioning Definition Development
20 stories ? ids 35 stories 80-100 ids 35 stories
Feature 4 stories ? ids + 23 later on
Containing
15 stories ? ids 25 stories 60-80 days 25 stories
Red, Green
& Gold 5 stories ? ids + 25 later on
Epics
15 stories ? ids 20 stories 55-60 ids 20 stories
5 stories ? ids +15 later on
15 Key Stories 80 Clear User Stories 80 User Stories Initially
Architecture Diagram 14 Unclear User Stories
GUI Prototype Feature Breakdown 63 Additional stories
Artefacts Customer Feedback Component Breakdown after second round of
Dependency Chart envisioning
Release Backlogs
1st Iteration 6 Weeks 2 Weeks 45 Weeks
2nd Iteration 2 Weeks 4 4 5 2 Weeks

12. Envisioning
Envisioning develops a clear product vision /roadmap to deliver the right
product to the right market using the right technology through consultation with
users and choosers.
10% of overall effort Prototypes
& Models
Market & Product Requirements
Technology AnalysisBrainstorming Backlog
Evaluations & Visioning Deliverables
Prototyping
Competitive Delta Risk
Analysis Acceptance
Criteria Backlog
Customer Field
QFD Studies & Interviews
House of Quality GUI
Guidelines
Practices Deliverables
n Brainstorming & visioning n Competitive n Requirements backlog n Risk
analysis (SWOT) n Delta analysis n QFD backlog n Analysis & Verification
n Customer studies n Hardware, platform & Reports n Prototypes/Models
component evals n Prototyping/modeling
n Look-and-Feel Guidelines
Whole Team Envisioning
All Stakeholders and All Roles
Team Attributes
§ Critical Thinking (know, understand, apply, analyse, synthesise,
evaluate)
§ Collaboration (patience, empathy, kindness, humility, listeners,
communicators)
§ Thinking (visual, system, lateral, pattern, methodical)
§ Expertise (domain or industry, skills, sound grasp of technologies)
How much time you spend envisioning
depends on how well you know the requirements and solution
©2009 Bedarra Research Labs. All rights reserved.

13. Typical Requirements Gathering Tasks
Data gathering
§ Secondary research using existing market and competitive
analysis ($)
§ Heuristic evaluations ($$)
§ Surveys and questionaires ($$)
§ Field studies and job shadowing ($$$) – Our preferred choice
§ One-on-one interviews ($$$)
§ Focus group interviews ($$$$$)
Problems
Problems Personas
Personas Stories
Stories Acceptance
Acceptance
Criteria
Criteria
Problems
Understand the problem before designing the solution
Understand your “great idea” in the context of solving a “real
problem”
Problem
Name Name of the problem
Description Detailed description of the problem
Evidence Any supporting evidence (e.g. reports, interviews, transcripts, call reports, help reports)
Persona Persona affected by the problem
For more on problems: http://www.pragmaticmarketing.com/publications/topics/01/requirements.pdf0

14. Problem Example
Problem
Name Cable management problem
Description Jane has spent hours redecorating her home office, choosing just the right
paint & furniture. Her new office looks sleek and modern except for.. the mess
of computer & monitor wires and cables snaking around and under her desk.
She thinks it looks ugly and distracts from the overall cool new look of the office
Evidence
Persona Affected Residential consumer
© community.featureplan.com/community/2007/09/more_on_problems.php and reformatted
Personas
Popularized by Alan Cooper (www.cooper.com)
Tangible way of representing and relating to the user
Persona
Name The persona name (e.g. George Smith) and a type (e.g. Business Consumer)
Gender Demographic information
Age Demographic information
Education Education level
Handicaps Special issues (e.g. glasses, hearing, physical or mental disabilities, etc)
Technology literacy Experience with technology, experience with this kind of application or other applications
Cultural bias Localization issues
Goal/Motivations Describe the behavioral goal of why the user would want to use this product
(e.g. likes to help people, scared of being laid off)
Job Description Describe the personas role in terms of responsibities and typical day
(i.e. provide the context for using the application)

15. Persona Example (Side 1)
©2005 http://personas.quarry.com/docs/QuarrySamplePersonas.pdf
Concurrent Exploration
Form and Function Exploration Technology Exploration
1.Do form and function analysis 1.Do technology analysis
2.Sort and prioritize tasks 2.Develop essential architectural
3.Identify primary persona and /design concepts
primary tasks. 3.Identify training, tools, skills
4.Develop one or more primary 4.Identify items that merit proof-of-
layouts and navigational models concept prototyping (e.g. usually
(e.g. task flow, wireframe, sketches) risk related items such as structure,
5.Develop secondary layouts api, security, performance,
as necessary scalability, platform issues)
6.Develop paper prototypes of the 5.Develop hardware/ software
most promising candidates prototypes
7.Identify things you need to learn 6.Evaluate suppliers
from users and choosers as you
may need to do a little more
prototyping

16. Typical Tasks
Brainstorming and analysis
Sorting and prioritizing (personas, scenarios, tasks, use
cases)
GUI Architecture and Design Concepts (e.g. organization and
navigation based on task flow; layouts …)
GUI Prototyping (e.g. task workflow)
Software Architecture (e.g. structure of new, changes to
existing)
Buy vs. Build Evaluation
Software Prototyping (e.g. derisking development through
exploration of design alternatives – form, function, security,
reliability, performance )
Typical Outputs
Product Vision and roadmap
§ Many forms ranging from slide to prototypes to videos
Paper prototypes
§ Card-flipping slide presentation
GUI architecture, wireframes, interface concepts
§ Visio or slide presentation
Core business logic
§ Example rules and actions, calculations, flows in tables,
spreadsheets
System architectures, diagrams, models
§ Slides
§ Architecture Views in Clouds, UML or Box and Connector
Diagrams, Patterns
Proof-of-concept software prototypes
§ Scripted or developed code with measurements showing key
aspects of the system

17. Functional Design Questions
What is the essential value of the feature (usefulness)?
How can we make the essential value obvious or visible
(usefulness)?
What is the balance between complexity and visibility
(usefulness)?
How would we classify this functionality?
§ Table stakes is deciding on whether to simply catch-up (speed)
or leap-frog (differentiate)
§ Competitive differentiator is balancing speed (first) with
innovation (best)
§ Nice-to-have issue is how to balance richness and complexity
Form Design Questions
Is this a “legacy” form?
– How much innovating can we really do?
Is this primarily a “form” opportunity?
– MP3 player was the functionality, but iPod was a form play
Does the persona or context imply a new form?
– Salesman suggests “portable”
– Doctor suggests “portable” and “pen”
What are our visionary competitors doing?
What are our niche competitors doing?
What are our customer’s saying about our legacy form?

18. Primary Layout Exploration Technique
Tables help you explore the user’s organizational or mental model
Organizational model Task Task
Location or map views
Used to show visual relationships between various display objects. X
(e.g. physical maps, network topologies, drawing, process, desktop)
Alphanumeric views
Used when tabular comparisons, search, filter are important X
(e.g. spreadsheets, alarm managers, email lists)
Time views
Used when time is an important relationship X
(e.g. project management, calendars, planners, animation)
Category views
Used when the category is the important relationship
(e.g. models, departments, organizations, classifications)
Hierarchy views
Used when seeing and understanding parent-child relationship is important X X
(e.g. tree structure-based applications like Explorer or Outlook)
Based on Richard Saul Wurman’s LATCH model. Read his book “Information Anxiety” for more information.
GUI Envisioning Explores
What does your primary persona think is cool/important?
Any useful emerging UI technologies ready for prime time?
– tablet, gestures, speech, haptic, table top, 2D bar codes
What delivery platforms are we going to use?
– C++, Java, C#, web 2.0, JSP/ASP/Flash/JS/CSS mobile,
wireless…
What does your primary persona use today?
– iPod, Blackberry, PC…
Is this a multi-technology delivery play?
Do we understand the UI technologies?
International and Universal Accessibility?
-

19. Software Envisioning Explores
Do we understand how this would be implemented?
Have we done anything like this before? Has anyone else done it
before? Can we reuse their solution? NIH?
What are the major “technical problems” that we can foresee?
Have we carefully considered all the “ilities”?
– security, performance, scalability, conformance, data
access, data manipulation, mobility
Are there areas where I just don’t know enough to have an
opinion?
Is this solution too complicated for the value it will be delivering?
ROI?
Are we using the right technology, components, suppliers?
Some Envisioning Practices
A few form, function and technical design techniques:
Design Technique Function Form Software
Task Sorting (Functionality Sorting) X X
QFD – House of Quality (Functionality X
Sorting)
Spreadsheets (Computation Rules) X X
Decision Tables and Trees (Logic Rules) X X
Domain Models, Class and Entity X X
Relationship (Object Relationship) Diagrams
Architecture Views – Conceptual, X X X
Flow…Physical
Interaction Diagrams and State Diagrams X X
Prototypes X X X

20. Task Sorting
Similar Similar Similar Similar
Primary Primary Secondary Support
Tasks Tasks Tasks Tasks
Primary Secondary Supporting
Tasks Tasks Tasks
Tablestakes 1 1
Tasks 11 31
Differentiator 1
Tasks 21
Nice-To-Have
Tasks
Quality Function Deployment - House of Quality
§ Focus on customer
§ Couples customer requirements and technical characteristics
§ Quantify choices
§ Focus development
§ Manage complexity
Source: http://www.gsm.mq.edu.au/wps/wcm/connect/internet/Root/research/researchclusters/cmit/tutorials/

21. Decision Tables
§ Simple way of getting customer head around complexity by structuring
logic
§ Captures conditions, situations and actions
§ Easily updated
§ Can generate code and test easily
No charges are reimbursed to the patient until
the deductible has been met. After the
deductible has been met, reimburse 50% for
Doctor's Office visits or 80% for Hospital visits.
There will be 4 rules. The first condition (Is the
deductible met?) has two possible outcomes,
yes or no. The second condition (type of visit)
has two possible outcomes, Doctor's office visit
(D) or Hospital visit (H). Two times two is four.
Source: http://web.sxu.edu/rogers/sys/decision_tables.html
Essential Architecture
The essence of the application and the solution
• Architect is a role not a job !
• Effectively communicate architecture
• Understand the technology/team and business
• Playing coaches
• Articulate the important architectural style and patterns
• Allow the architecture to emerge
• APIs versioned in the code base
• Should ALWAYS be able to create the architecture
pictures from the code
©2004 Bedarra Research Labs. All rights reserved.

22. Communicating the Architecture – Put It On The Wall
ER Data Model
Interaction Diagram
Domain Class Model
Architecture Wall - Mapping Stories To Architecture
Identify work load based on architecture
Identify bottlenecks
Identify efficiencies (e.g. functionality required by N stories)
Identify feature and component teams affected
Dashboard Feature
Platform Layer Service Layer Application Layer Reporting Epic
User Stories
User Stories
Database Component …
…
Client Add report
Add report
Edit report
Edit report
Delete report
Delete report
List reports
List reports
Search reports
Search reports
Copy and paste reports
Copy and paste reports
Print reports
Print reports
Configure report attributes
Configure report attributes
Format reports
Format reports
Database Component Server Configure reporting database
Configure reporting database
…
…

23. Mapping Stories Against The Architecture Wall
Create a working ‘thin slice’ through the architecture
Also called tracer bullets, essential use cases
Allows you to test functionality and show progress to stakeholders
Example: ‘S1, S45, S22 and S18, we can show a simple search…’
Platform Layer Service Layer Application Layer
S18
Database Component Client
S1
S45
Database Component Server
S22
Extreme Design - Design and Cost in 2 – 4hrs
• Systems Engineering practice to respond to bids
• Small team 3 – 5 spend 2 – 4 hrs
• Essential System Design
• What we know?
• What we don’t know?
• What will it cost to build?
©2009 Bedarra Research Labs. All rights reserved.

24. Prototyping
Types of prototypes (working models)
§ Business, capability, usability, performance prototypes*
§ Fidelity should be as high as it needs to be; pay now or pay
double later
Use low-fidelity prototyping to explore:
§ Business (e.g. new functions, integrations)
§ Functionality or Capability (e.g. new functions, features,
workflow)
§ User Experience (e.g. organization, navigation, appearance,
accessibility, usability)
Use software prototyping to explore:
§ Key Architecture/Design alternatives
§ New Technologies
§ Component suppliers
§ Performance (e.g. transaction rates, data storage access and
retrieval, response times, throughput, concurrency)
* See http://en.wikipedia.org/wiki/Software_prototyping
Value of Prototyping
GUI prototyping helps you design the system
“A GUI picture is worth a thousand stories” Use Cases In This Picture
Makes functionality concrete and tangible 1.
2.
Open business area
Print business area
3. Email business area
Creates shared vision of the product 4. Export business area
5. Filter business area
6. Page list
7. Open help
8. Add report
9. Add dashboard
10. Add report configuration
11. Add dashboard configuration
12. List reports
13. List dashboards
14. List report configurations
15. List dashboard configurations
16. Open or view report
17. Copy report
=
18. Move report
19. Delete report
20. Open or view dashboard
21. Copy dashboard
22. Move dashboard
23. Delete dashboard
24. Open or view report config
25. Copy report config
26. Move report config
27. Delete report config
28. Open or view dash config
29. Copy dash config
30. Move dash config
31. Delete dash config

25. Low-Fidelity Prototype Example
Low-fidelity prototype
§ Initially rough and then later refined drawings
§ Interactive branching allowed walkthrough
§ User model, task model, task flows
§ 3 structure and navigation alternatives
§ 2 visual form alternatives
Concept iterations
§ 6 iterations (expanding from 8 to 48 screens)
§ 3 sprints
§ 3 internal / 2 external customer sessions
Detail iterations
§ 3 iterations (148 screens)
§ 8 sprints
§ 3 internal / 1 external customer sessions
Investment
§ Less than 2% of overall effort
Envisioning Improves Backlogs and Flow
Are we building the right product, using the right
technology for the right ROI?
Explores Feasibility
Exposes Risks
Explores Solutions Alternatives
Evaluates Technology Alternatives
Enables early customer/business feedback
Ensures that backlogs have sufficient detail to be tangible
Ensures that backlogs have acceptance criteria
DONE when the items are tangible and prioritized, such that
there is enough clarity to commence development.

26. Successful Software Development is about a
Winning Culture
Software is a team sport, and like all team sports practice,
constructive peer feedback, and coaching are essential.
Winning teams need to implicitly know the moves of each player, as
well as the movements of the team as whole.
The ultimate expression of process is a culture where building
software is more like playing jazz. People Just Do It!
Obrigado!