what is 'just enough' documentation in agile?

Post on 29-Aug-2014

5.113 Views

Category:

Business

1 Downloads

Preview:

Click to see full reader

DESCRIPTION

There are lots of misconceptions around what Agile says about documentation. One is that Agile has NO Documentation! That brings a smile to a few folks and drives others (like me) crazy! If you’ve read anything about Agile, you’ll hear that what it really preaches is ‘Just In Time’ or ‘Just Enough’ documentation. So what does that mean? Why aim for ‘Just Enough’ and not ‘Perfect’ Documentation? This seminar was presented at the IIBA group. Want this seminar presented at YOUR organization? just email sally@agiletransformation.com

TRANSCRIPT

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.

• Sally@AgileTransformation.com

• 402 212-3211

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

• 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

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

4

Agile Requirements

Characteristics

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

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

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

10

The Backlog Hierarchy

Business Domain

Theme/Feature/Epic

Story1 Story2

Feature2

Story3

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

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.

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

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.

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

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

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

16

Sample Release Backlog

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

17

Sample Release Plan

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

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?

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

19

Sample Business Process

Diagrams

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

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.

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

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.

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

22

Sample User Test Cases

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

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.

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

24

Sample Test Results

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

25

Sample UI Prototypes

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

26

Sample Activity Diagram

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

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

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

28

Managing Change

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

29

Tracking Progress

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

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.

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

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

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? Sally@AgileTransformation.com

Resources

34

top related