what is 'just enough' documentation in agile?

Presenter: Sally Elatta

What is ‘Just Enough

Documentation’ in Agile?

1

About the Speaker

• Sally Elatta

• Founder of AgileTransformation.com

• Enterprise Process Improvement Coach, Architect, Trainer

• Coached over 18 teams on adopting Agile methods.

• Taught over 600+ students on Agile

• Certified ScrumMaster, Scrum Practitioner, IBM, Sun, and

Microsoft Certifications.

• [email protected]

• 402 212-3211

Copyright(c) Sally Elatta 2009 www.AgileTransformation.com2

mailto:[email protected]

• Review of our last session

• The Agile view on requirements

• Reviewing what is ‘Just Enough’ for each

Agile phase

• Sample requirements

• Resources

Session Goals

Copyright(c) Sally Elatta 2009 www.AgileTransformation.com

3

Traditional Requirements

Characteristics


4

Agile Requirements

Characteristics


55

The Agile Lifecycle – Big Picture

During Release Planning

– Breakdown requirements into stories– Need ‘Just Enough’ Discussions to

breakdown a story

– Build a complete backlog

– Need ‘Just Enough’ Discussions to identify all stories

– Prioritize based on value and dependency

– ‘Just Enough’ related to priority

– Estimate/Size each story

– ‘Just Enough’ to estimate a story (*)

– Build the Release PlanCopyright(c) Sally Elatta 2009 www.AgileTransformation.com

7

What is a Story?

• A small piece of requirement that is ‘valuable’ to the business.

Follows these attributes:

Understandable

Independent

Negotiable

Valuable

Estimatable

Small

Testable

Story Format:

“As a <role>, I want to <goal>, so I can <value>”

Sample Stories

As an Agent I want view the ‘Current Leads’

report.

As the EDW System, I want to

have ABC file loaded on a schedule.

As a BA I want to define the

existing product return process so I can identify any

inefficiencies.

As an Agent I want to enter

new lead information so I can track them.

As the XYZ system I want to receive

new member enrollments each night so I can process them.

Sample Use Case Diagram


10

The Backlog Hierarchy

Business Domain

Theme/Feature/Epic

Story1 Story2

Feature2

Story3


11

Non Functional/

Foundational Stories

• Your backlog is not ‘Complete’ without identifying and planning for non-functional system stories.

• Typically scheduled for iteration 0 or sprinkled throughout other iterations.

• Identified by the team (DBA, Security, Infrastructure, Architect, Developers ..etc)

• Iteration 0 needs to complete ‘Just Enough’ foundation stories for iteration 1 to be successful.


12

Sample Foundation Stories

Develop High Level Service Architecture

Diagram

Setup and Configure

LDAP

Develop High Level Process

Diagram for the ‘Get a Quote’

process.

Setup and configure XYZ Test Server

Setup ABC Database.

Build Logical Design Model.

Story Points

• We simply use relative complexity buckets

to size each story.

Copyright(c) Sally Elatta 2009

www.AgileTransformation.com14

Smallest

20+

Small Medium Med-large Large Very Large EPIC!

How many stories a team gets ‘Done’ each iteration is their Velocity

Agile View on Estimates

• Looking for relatively good estimates instead of precisely accurate ones.

• Done by the team who will actually do the work.

• Updated throughout the project.

• Measure stories in relative complexity points.

• Measure tasks in hours.

• Measure ‘Velocity’ from actual team performance.

• Estimate in detail near term efforts, plan higher level for following ones.


15

‘Just Enough’ to

Estimate a Story

• Need ‘Just Enough’ discussion to estimate

the story’s complexity.

• Do not need to know detailed business

rules and exact solution implementation

details.

• ‘Just Enough’ is reached when the team

can size the story.

Let’s explore the sample guide


16

Sample Release Backlog


17

Sample Release Plan


18

View Sample Release Plan

During Iteration 0

• ‘Just Enough’ for iteration 0 could include:

– High level architecture diagrams

– High level business process diagrams

– High level data logical diagrams

– Look and Feel Template

– System straw-man

– What else?


19

Sample Business Process

Diagrams


20

During Development Iterations

• Now come the details!

• Team must first define what makes a

story ‘Done’

• Then we can decide on what is

‘Just Enough’ to get us there.


21

Sample Definition of ‘Done’

• Story Level:

– All unit tests have passed.

– Code review is complete and code is checked

in to source control.

– UI Branding has been applied.

– All acceptance test cases have passed in

the test environment.

– No outstanding bugs exists for this story.


22

Sample User Test Cases


23

“A customer can pay for shopping cart items using a credit card”

Test with VISA, MasterCard and American Express (pass)

Test with Diner’s Club (fail)

Test with bad and missing 3 digit codes (fail)

Test with expired cards (fail)

Test with a purchase amount over the card limit (fail)

Sample Business Rules

• 1.1-TC1 ‘Verify that student eligibility rules are

applied correctly during registration’

– TC1-BR1: Students with a ‘hold’ record cannot

register on the site.

– TC1-BR2: Students with outstanding payment from

last semester cannot register.

– TC1-BR3: Student already registered cannot register

again.


24

Sample Test Results


25

Sample UI Prototypes


26

Sample Activity Diagram


27

The Wonderful ‘Traceability’

Question

• Here is an Agile traceability matrix:

> 1 - Feature

> 1.1 Story

>1.1 – TC1 Test Cases

> TC1-BR1 Business Rules

>BR1-T001 Test Scenario Results

>Tasks

>Code


28

Managing Change


29

Tracking Progress


30

Summary

• To know what is ‘Just Enough’ you need to know what your immediate next goal is.

• Agile invests cautiously on detailed requirements by doing it just-in-time so it can stay flexible to requirements change.

• ‘Just Enough’ does not equal ‘Not Good Enough’!

• Agile encourages lightweight easy to understand and maintain documentation.


31

How We Can Help

Training

• Executive and Business Overview of Agile/Lean

• Real World Agile and Scrum team training + Project Jump Start

• Effective Facilitation & Requirements Gathering

• Servant Leadership

• SOA

• … More!

Coaching & Consulting

• Troubled Project Assessment & Recovery

• Agile Project Initiation and Planning

• End to End Project Execution

• Organizational Assessments

• Process Improvement Roadmap Execution

http://agiletransformation.com/index.php/training/agile-training/real-world-agile-and-scrum/



http://agiletransformation.com/index.php/training/agile-training/mastering-the-art-of-facilitation/

http://agiletransformation.com/index.php/training/agile-training/effective-requirements-gathering/

http://agiletransformation.com/index.php/training/agile-training/becoming-a-servant-leader/

http://agiletransformation.com/index.php/training/technical-transformation/

This Seminar for YOUR

Company

Contact me if you’re interested in this seminar for your own

organization. Either in person or over the web. It could be FREE if you

qualify

• www.AgileModeling.com

• http://www.agilemodeling.com/essays

/agileRequirementsBestPractices.htm

• Questions? [email protected]

Resources

34

http://www.agilemodeling.com/

http://www.agilemodeling.com/essays/agileRequirementsBestPractices.htm

http://www.agilemodeling.com/essays/agileRequirementsBestPractices.htm