Agile requirementspraguefinal

© 2009 IBM Corporation

Agile Requirements and Context Counts

Cherifa [email protected]

WebcastAgile community in Prague

2Agile Requirements at Scale

Goals

� To understand what do we do differently in agile?

� To show that requirements still matter in agile

� To understand agile requirements practices

� To show that context counts, and one “process size” does not fit all

� To explore how to scale agile requirements practices


Agenda

1

4

3

2

Agility and requirements

Achieving better requirements on agile

projects: User stories and beyond

Brief introduction to Agile requirements at scale

3

Conclusion


Agile Requirements: Strategies are changing� Continual customer involvement

�Product owner represents the stakeholders

� Shared vision

�Understand business needs

�Focus on stakeholders goals

� Requirements elicitations

�Conversations, agile modeling, workshops

� Requirements analysis

�Performed “just in time”

� Requirements documentation

�User stories, storyboards, acceptance tests, agile models

�Test your documentation effectiveness : ”CRUFT” Measure

� Formality

�Improvised, more relaxed approach


Traditional requirements practices are changing

� Specify acceptance tests while you gather requirements

� Iterative requirements planning & management

�adjusted with planning levels to take into account the progressive

requirements specification

Day

Iteration

Release

Product

Iteration

Day

Release

Product

Portfolio

Strategy

Most agile teams are

concerned only with

the three innermost

levels of the planning

onionSource: Scrum


Agile brook down the barriers Prioritized

Requirement List

Agile Team Collaborates with Customer

TestsCode

Requirements

specs

Tests

Code

Master story

List

Add user

Create profile

Book

reservation

Make payment

Agile planning 101Requirements

One whole team

�Done

�Done

�Done

Silos

Velocity

+ MORE


Agenda

1

4

3

2


Achieving better requirements on agile



7

Conclusion


Agile Requirements Practices : How much is enough?


Agile Requirements: User Stories

� User story is a concise, written description of a piece of functionality that will be

valuable to a software stakeholder

�As a <role>, I can <goal> so that <business value>

� Epic User Stories are very large user stories

� Break epic stories into iteration-stories

� Product Backlog contains ranked list of user stories for a release

�User Stories are created at the beginning of the release

�Product Owner ranks list based on highest need to stakeholders

�But< with input from team, e.g. high risk items rank high

10Agile Requirements at Scale 10

User stories: Ron Jeffrey’s 3 Cs

Record what you learn in an acceptance test.

Example:

Student can access course catalog 24 x 7 hours

Student cannot choose more than three courses

Confirmation

How to verify if the

story is done and

complete, and the

goal is achieved

Discuss the card with a stakeholder. Just in time analysis (JIT)

through conversations.

Example:

What information is needed to search for a course?

What information is displayed?

Conversation

How to achieve the

goal using the

system?

As a (user role), I want to (goal) so I can (reason)

Example:

As a registered student, I want to view course details so I can create

my schedule

Card

What is the goal of a

user

A user story has 3 parts. If it doesn't, it's not a user story.


Acceptance tests

�Acceptance tests are high level tests and captured as confirmation

�They test the completeness of a user story or stories 'played' during any sprint/iteration.

�They verify that the user’s goal is achieved using the system

�Write acceptance tests before coding

�Non-functional requirements and business rules are often captured as part of acceptance tests

�Engage customer to define acceptance tests

• Student can access course

catalog 24*7 hours

• Student cannot choose more

than three courses

Are these

acceptance

tests?As a registered

student

I want to access

course catalog

content so I create

my schedule


Acceptance Tests Examples


Why use User Stories?

� Right size for planning, works for iterative development

� Defer detail until you have the best understanding you are going to have about what you really need

� Focus on user goals and business values

� Emphasize verbal rather than written communication

� Comprehensible by both Stakeholders and the dev team

� Stories support evolutionary development


Definition of Done

� Every story needs to meet this definition to be counted

� Start with a manageable definition of Done

� Review definition of Done each iteration, try to add to it

� Done

�No Sev 1, Sev 2, Minimal Sev 3, Sev 4

�Code reviews completed

�80% Unit test coverage

�Test automation completed

�Documentation complete and reviewed


Putting everything together: Iteration Planning

� Iteration Planning

1. Pull stories from the top of your ranked list

2. Use the team velocity to determine how many stories to include in iteration

� Velocity = total story points completed on average over last ~ 3

iterations

3. Define Acceptance tests

4. Define the tasks required to complete the work

As a customer I want to be < 5


As a administrator I want < 2

As a business planner I < 3


As a administrator I want < 2

As a product owner I want < 5



Product Backlog Size

Ran

k O

rde

r

Velocity ~ 20

0

10

20

30

40

50

60

Iterat ion 1 Iterat ion 2 Iterat ion 3 Iteration 4 Iterat ion 5

Story Points Targeted

Story Points Completed

Velocity of ~20,

Select top 5

stories (21 pts)


Agenda

1

4

3

2


Achieving better Requirements on

agile projects: User stories and

beyond


1

6

Conclusion


Domain Complexity

Straight-forward

Intricate/Emerging

Compliance requirement

Low risk Critical,Audited

Team size

Under 10developers

1000’s ofdevelopers

Co-located

Geographical distribution

Global

Enterprise discipline

Projectfocus

Enterprisefocus

Technical complexity

HomogenousHeterogeneous,

Legacy

Organization distribution(outsourcing, partnerships)

Collaborative Contractual

Agile scaling factors

Disciplined Agile

Delivery

Flexible Rigid

Organizational complexity


Things to consider when you are scaling?

� Features , Use Cases, or User Stories

� How much discipline?

� Automation is the rescue?

� Need additional level of planning?

� Documentation?

� Reviews? Drive


Use Cases or User Stories? Use Context

A user story is<

� a simple, clear, brief description

� expressing a user’s goal for

using the system under

development

� to deliver business value

A use case is<

�the specification of a set of actions

�performed by a system,

�which yields an observable result that is, typically,

�of value for one or more actors or other stakeholders of the system. (Unified Modeling Language - UML 2.0)

�Both methods are focusing on users and values to the users.

�Each has its own strengths and weaknesses.

�How do we bring together the best of the both worlds for Agile

Requirements at Scale?


Scaling factors make Agile hard? CLM to the rescue Prioritized/ranked Requirements List

Team velocity

Visibility to the whole team

Master story List

Add user

Create profile

Book reservation

Make payment

Agile planning 101

Test Scripts

DefectsStories

Builds

Sprint

Lifecycle traceability

Continual Improvement

Collaboration


Agile requirements and large teams

� Communication and coordination risk increases with large teams

� Initial requirements and architecture envisioning is critical

� Coordination of requirements between subteams is important

� Team organization, architecture, and requirements must reflect each other

� Re-enforce the usage of product backlog for scope management

� Use simple tools, apply some agile practices such as active participation of

stakeholders


Agile requirements and regulatory compliance

� You may need to adopt other requirements

strategies, such as use cases or formal System

Requirements Specifications (SRSs)

�BUT... read the regulations, because they likely don’t

specify how, nor when, to capture the requirements

� Traceability is often a secondary, but important,

part of the regulation

�BUT< read the regulations, because they likely don’t

specify the level of detail required

� You will likely need to write more documentation,

particularly business rules and requirements

pertaining to sensitive data

�BUT< read the regulations, because you only need to

do this to the extent of the risk of the project

� You may need to hold reviews

�BUT< read the regulations, because they seldom

require formal reviews


Agile requirements and geographically distributed development

� Geographically distributed teams incur

significant communication risk

� Need a more “disciplined” agile

requirements approach

�One that can address risks

�Automation is a “must” for requirements

traceability, version control and

collaboration

�Requirements dashboards and reporting

on certain important measures become

necessary

� Large team considerations apply


Agile requirements and domain complexity

� Business process sketching may help

understand the complex domain

environment

� Might want to consider light-weight use

cases instead

� Will likely need to do more user interface

(UI) prototyping

� Active participation of stakeholders

throughout the life cycle is crucial for you

to understand their changing needs

� Important: Complex domains don’t imply

that you need detailed requirements

speculations

Rich-text, Images, links

Process Sketches

Shared Glossaries

UI Sketches and StoryboardsUse Cases

Feedback and Dialogue


Agenda

1

4

3

2


Achieving better Requirements on agile



2

5

Conclusion


Implications for Business Analysts (BA)

� The BA goal is to build a shared understanding, it isn’t to write detailed

documentation

� Expand your horizons and become a generalizing specialist

� Learn how to perform acceptance TDD so that you can capture requirements as

executable specifications

� Recognize that one process size does not fit all, that you will need to be flexible

� Your primary goals should be to:

�Facilitate communication between stakeholders and developers

�Put developers in direct contact with stakeholders wherever possible

�Help developers learn better communication skills


Implications for Organizations

� Don’t be fooled by the agile rhetoric

�You still need to invest in modeling

�You still need to invest in requirements management

� Don’t be fooled by the traditional rhetoric

�Detailed documentation adds risk to IT projects

� Individual teams find themselves in unique situations, so will have

unique tailorings of your process


2

8

© Copyright IBM Corporation 2010. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, Telelogic, the Telelogic logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.

www.ibm/software/rational/agile/

Date post:	13-May-2015
Category:	Education
Upload:	matous-havlena
View:	708 times
Download:	0 times

Agile requirementspraguefinal

Education