You are on page 1of 27

Agile Use Cases

(Driving Development)

B J E C T IV E S
www.netobjectives.com
info@netobjectives.com

Net Objectives, 11/06/15

NetObjectives

My Goals

Enlighten

Teach

Inspire
Net Objectives, 11/06/15

NetObjectives

The Purpose of Software


Development is
To provide a suitable solution for users
That consists of quality code
And doesnt cost too much

Where Use Cases Live


Suitable = Useful +
Usable

Net Objectives, 11/06/15

NetObjectives

What is a Use Case?


From an Analytic Perspective, a use case is way
to discuss with users how the system will enable
a user to get something done
However, from a Development Perspective, a
use case is a collection of scenarios that have
to be coded up
Success scenarios
Alternative scenarios
Failure scenarios (graceful degradation)
Bugs (new failure scenarios)

We Use Scenarios as the Basis for our Work


Net Objectives, 11/06/15

NetObjectives

The Purpose of Use Case Analysis


To develop scenarios that drive development
We want a system that works
Whose scenarios get the job done
Usable would be nice

This talk is about Agile Development, so


Scenarios are developed as they are produced and
prioritized
Developed scenarios are validated as they are
produced
Scenarios are developed as soon as possible, so that
we can have something to show our customers and
users
Net Objectives, 11/06/15

NetObjectives

We Validate a Scenario Four Ways


before we Actually code it up
Is it useful?
Did it satisfy its post-conditions?

Is it usable?
May require storyboards and wireframes to validate

Is it buildable?
Must verify with developers that fits within
architectural scheme, etc

Is it testable?
Can we envision the test scenarios we need to test
it?
Net Objectives, 11/06/15

NetObjectives

good Team Philosophies, leading to


Agility
One Bite at a Time: reminds us to do things a little at a time,
with planning, validation, and management of the pieces.
Validation Centricity: reminds us that the activities of
validation, verification and test are more important than
those of analysis, design, and construction; and that we must
actively look for things that cause us to change.
Dont Do What you Dont Need: work on those things with
the most value; avoid analysis paralysis, and keep moving
Quality Cant be the Variable: When balancing the three
main variables (scope, time, quality), quality cant be the one
that slips
Let the Product Lead: decisions must be based on the
product, not documented plans, analyses, requirements, or
designs.
Net Objectives, 11/06/15

NetObjectives

Managing the Building of Product


Work Backlog: an evolving, prioritized queue of
business and technical functionality that needs
to be developed into a system (Source: Scrum)
Story: Describes some item of value to a user
or product owner (Source: XP, Cohn)
Task: Well-defined unit of work in the process
that provides management with visible
checkpoints into the status of the project. Tasks
have readiness criteria and completion criteria.
[Jones - IBM] (Source: SEI:SE-CMM)
Net Objectives, 11/06/15

NetObjectives

Example Stories
Description: Shop for Round Trip Flights
Size: Big
Validation: Functional test each Scenario

Description: Round Trip, single passenger, no luggage,


no seat selection, one leg
Size: Large
Validation: Functional Testing

Description: Add the Cello


Size: Small
Validation: Functional Testing

Description: Help Marketing Prepare materials for the


trade show
Size: Large
Validation: Inspection by Marketing

Net Objectives, 11/06/15

NetObjectives

Example Tasks
Description: New build script
Estimate: 6 hr
Owner: Sue
Exit Criteria/Verification: Build succeeds, Joe will inspect results

Description: Add the multi-passenger check-box to the


EntryScreen
Estimate: 4 hr
Owner: Joe
Exit Criteria/Verification: Unit tests written and passed

Description: SQL Training


Estimate: 2 days
Owner: Sue/Joe
Exit Criteria/Verification: training completed

Net Objectives, 11/06/15

10

NetObjectives

The Basic Development Loop


For Each Iteration you:
Plan
Whats the next stuff to do?

Simplified Scrum
(an agile process)

Analysis Work
Design Work
Implement some
functionality
Write Functional Tests
Run Functional Tests

The team decides how much


it can do

Perform You do it
Evaluate You evaluate both
the Product and the Process

Repeat
You manage this iteration with
the Work Backlog

Net Objectives, 11/06/15

11

Work
Backlog:

NetObjectives

Needs, Use Cases, Stories, Tasks


Creates Work We Need to Manage
Heres what I recommend for the major steps in
moving from a Users need to a collection of
Developer Tasks
Need

Business Level
Use Case

Detail a Use Case

Ever-Unfolding Story

Product Level

Scenario/
User
Story
Story
User
Story
User
Story

Iteration Planning Game

Development Level
Net Objectives, 11/06/15

Task
Task
Task
Task
Task
Task
Task
Task
Task
Task
Task
Task
12

NetObjectives

Use Cases arent the only thing going on


ATM Project

Product

Function

Team

Structure

Business

Management

Sales Spt

Team
Training

Marketing
Support

Login

Conversions

Dev/SCM/Test
Environments

Withdraw
Cash

User
Training

Rewrites

User Docs

Deposit
Check

Dev
Process

Refactorings

Transfer
Funds

App
Framework

Business
Framework

Tools

Adapt
Processes

Maintenance
Docs

Refresh Cash
Drawer

Net Objectives, 11/06/15

The Use
Cases
Populate the
Function
Leg
13

NetObjectives

Generating Scenarios for the System


What Is The
System For?

What Should The


System Do?

Vision

Context
ual Stud
ies
Task An
alysis

Usability Concerns

Use Case List

What Should This


Use Case Do?

Pre/Post-Conditions

How Do We Make
It Do That?

Basic Scenario

What Could Go
Wrong?

bil
a
Us

it

on
C
y

rns
e
c

UI Design,
Development,
Refactoring

Alt Scenario

What Pieces Do
We Need?
What Else Might It
Do?

What Could Be
Different?

Net Objectives, 11/06/15

Design and
Development

Ext Scenario

Parallel Scenarios

14

NetObjectives

Adding Business Value for a Use Case

design/develop/refactor

Time/Efort

analysis
S

developed scenarios

Business Value
Net Objectives, 11/06/15

15

good enough

NetObjectives

My Assumptions About Usability


That it can be done incrementally
That minimal up-front analysis needs to be done
This doesnt mean none, though, IMHO

That interfaces can be refactored together as


we go
That middle tier can be separated from UI
layer in order to separate logic from interface in
such a way that logic persists even if UI
changes

Net Objectives, 11/06/15

16

NetObjectives

Let the Games Begin

Net Objectives, 11/06/15

17

NetObjectives

Net Objectives, 11/06/15

18

NetObjectives

Net Objectives, 11/06/15

19

NetObjectives

Net Objectives, 11/06/15

20

NetObjectives

The importance of up front studies and


scoping
[Jon] These are of paramount importance the
more time you spend on these the better.
[Dan] Do just enough to feel comfortable, then
dig in. Refine as you go, knowing that you
probably didnt get it right, but hoping that you
got close enough

Net Objectives, 11/06/15

21

NetObjectives

Analysis paralysis how much is


enough
[Jon] Analysis paralysis is a boogie man that
programmers constantly raise because they
dont feel the project is started until you begin
coding.
[Dan] Analysis Paralysis is a trap for everyone.
You defeat by constant validation and moving
forward once you have enough. Not what you
think is enough, but what the team thinks is
enough.

Net Objectives, 11/06/15

22

NetObjectives

User interface integrity & consistency


[Jon] These are critical factors that affect
usability they depend on adequate scoping,
development of a conceptual model (the model
offered to the user to help them form their
mental model), a UI that covers most of the
scope, and a Style Guide.
[Dan] It would be nice, but it is more important
that the system accomplishes its mission,
making is usable is different than making it
nice to use
Net Objectives, 11/06/15

23

NetObjectives

Conceptual model development


[Jon] Few good UIs can depend on metaphors
what you really need is a good understanding of
the major objects and processes that the user
interacts with and what they mean to the user.
[Dan] Agreed. And this can be done best by
exploring the objects as they come up in
analysis and development throughout the agile
process; doing it up front leads to hasty (and
probably incorrect) conclusions.

Net Objectives, 11/06/15

24

NetObjectives

Style Guide development


[Jon] There are several levels of Style Guide
required: corporate branding, product family,
and product specific.
[Dan] No doubt. The questions are how soon
do you need it? and When does it get
developed?

Net Objectives, 11/06/15

25

NetObjectives

Detail design of user interface


[Jon] The more of this that can be done before
coding gets started, the better.
[Dan] Do it one scenario at a time, and refactor
them together. UI designers cant help looking
forward to future scenarios in order to lay out
their real estate on the screen, but they must
realize that they are probably going to have to
change things once those scenarios actually
come up for development.

Net Objectives, 11/06/15

26

NetObjectives

Usability testing during agile


increments
[Jon] Real usability testing is required demos
to users dont work.
[Dan] Depends on the iteration. Release
iterations require extensive usability testing, just
as they require extensive QA. Development
iterations only require demos and testing to
make sure that risks are being properly
mitigated.

Net Objectives, 11/06/15

27

NetObjectives

You might also like