Project Management in Agile Organizations - Agile Requirements

1
Agile requirement
process
NFI - Project Management in Agile
Organizations @ Tele2

Traditional requirements
Team
Requirement
2

SRS are “flat”,
requirements grouped in categories
3NFI - Project Management in Agile

Agil requirements
Team
Features
Vision/Goal Constraints
4

Source: Jurgen Appelo
What shall be
achieved, what
value to create for
whom.Constraints;
Brand, platform, to
ols, uptime, throyg
hput, budget, legal
, time etc.
Agil requirements
Agil Projektledning 5

Team
Product/Program
management
Executive management
What to be done.
Where we are heading-
Stories, Tasks
How to do it
Agile requirements are hieratical
6

Mike Cohn
http://www.mountaingoatsoftware.com/presentatio
ns/introduction-to-user-stories

Agile requirement hierarchy,
Mike Cohn
Theme
Epic
Story Story StoryStory Story Story
Epic
Task Task

Dean Leffingwell
www.scaledagileframework.com

Agile requirement hierarchy,
Dean Leffingwell
Theme
Epic
Story
Feature
Story
Epic
Task Task
Epic
Feature

Dean Leffingwells Model

Themes, Epics, Features, Stories & Tasks
• Themes
– Key product value propositions that provide market differentiation and competitive advantage.
• Epics
– The highest level of customer needs.
• Features
– Services provided by the system to fulfil stakeholder needs.
• Arch
– Architectural features are technical system services that allow developers to implement business
features that deliver solution value to the end users and the enterprise.
• User Stories
– Is a brief statement of intent that describes something the system needs to do for the user.
• Spikes (XP)
– A story to drive out uncertainty and risk with a new technology or domain.
• Tasks
– Is a small unit of work that is necessary for the completion of a story.

Team
Produkt/Programle
dning
Business management
Roadmap//Functions/
Constrains
What to be done.
”Themes/Epics”
Where we are heading-
Stories, Tasks
How to do it
Agile requirements are hieratical
14

User Stories
• A user story describes functionality that will be valuable to
either a user or purchaser of a system or software. User
stories are composed of three aspects:
– a written description of the story used for planning and as a
reminder
– conversations about the story that serve to flesh out the details
of the story
– tests that convey and document details and that can be used to
determine when a story is complete
http://www.mountaingoatsoftware.com/presentatio
ns/introduction-to-user-stories http://www.youtube.com/watch?v=6q5-cVeNjCE

User stories are the primary object that
carry the customer’s requirements
through the value stream – from needs
analyses through code and
implementation.

User Story Format
A <role> can <action>
or
As a <role>
I want to <action>
So that <value>
A company can pay for a
subscription with a credit
card.
As a consumer I can see my
daily energy usage so that I
can lower my energy costs.

Card, Conversation, Confirmation

Why User Stories?
• User stories emphasize verbal communication.
• User stories are comprehensible by everyone.
• User stories are the right size for planning.
• User stories work for iterative development.
• User stories encourage deferring detail.
• User stories support opportunistic design.
• User stories encourage participatory design.
• User stories build up tacit knowledge.

User Stories should be:
• A function – not an implementation
• Independent
– Not linked to other stories.
• Negotiable
– A base for discussion.
• Valuable
– For an identified user/customer/stakeholder.
• Possible to estimate
– The developers must understand what is needed.
• Right size
• Verifiable

A warning by Mike Cohn
One warning sign of a project going astray with a requirements specification is a ping-ponging of the specification
document between the software development group and another group like Marketing or Product Management. What
typically happens is the Product Management (or similar) group writes a requirements specification that is given to the
developers. The developers then rewrite this document so that it conveys their interpretation of the requirements as
first written by Product Management. The developers are always careful to give their document a completely different
name (something like Functional Specification perhaps) to hide that it is the same document as the initial
document, just written from the perspective of a different group.
Both groups know that a requirements specification for a project of any significance is too difficult to read and fully
understand and impossible to write with the desired precision. So, whichever group writes the final requirements can
claim ownership of the intent of the document. When the project is finished and blame is being allocated they will
point to sections of the document and claim that missing features were implied. Or they will claim that expected
functionality is clearly out of scope because of a sentence buried somewhere in the document.
Most of the times when I see two groups writing separate versions of essentially the same document I already know
they are positioning themselves for the end-of-project blame sessions and for claiming to know the intent of the
document. This type of silliness goes away with user stories. Along with the shift to conversations from documentation
comes the freedom of knowing that nothing is final. Documents that look like contracts feel so final.
Conversations don’t feel that way. If we talk today and then learn something next month, we talk again.

Everything is not user stories
• Descriptions of user interface (UI)
• Descriptions of (API)
• ..

Constraints & non-functional
requirements
Source: www.agileproductdesign.com
23

Define constraints on cards.
• Do not make it hard to internationalize the software if
needed later.
• The new system must use our existing order database.
• The software must run on all versions of Windows.
• The system must achieve uptime of 99.999%.
• The system must manage 200 transactions / second.

Use Case /User Stories
• Use cases are often permanent artifacts that continue to
exist as long as the product is under active development
or maintenance.
• Stories, on the other hand, are not intended to outlive the
iteration in which they are added to the software. While it
is possible to archive story cards, many teams simply rip
them up.

Personas
26

Impact map
NFI - Project Management in Agile Organizations @ Tele2

http://getlit.me/impact-mapping/

Agil Projektledning
Källa: HeltSonika

Agila kontrakt, Knowit 2013.05.29
Källa: HeltSonika
Funktioner
Logga in
Välja
språk Söka
Visa karta
Uppdatera
karta
Editera
information
Themes
Epics

Project Management in Agile Organizations - Agile Requirements

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Project Management in Agile Organizations - Agile Requirements

Semelhante a Project Management in Agile Organizations - Agile Requirements (20)

Mais de Knowit_TM

Mais de Knowit_TM (20)

Último

Último (20)

Project Management in Agile Organizations - Agile Requirements