How Agile Architecture can bring value to an Agile team? How can we use the Architecture tools to provide a better estimation?

1. User Story estimation with Agile
Architectures
R. Garofalo - IFC
@raffaeu

2. Agenda

Agile Architecture

User Story

Common Estimation Mistakes

Views and Viewpoints

Introduce Viewpoints in User Story estimation

Agile R.O.I.

The Estimation Game

3. Who I am

Raffaele Garofalo


IASA Member


Software Architect
Kitesurf addict
Contacts

Twitter: @Raffaeu

Blog: http://blog.raffaeu.com/

Mail: raffaeu@gmail.com

4. Introduction to Agile Architecture

What is agile architecture?

Agile Architecture key objectives

Agile Architecture principles

5. What is Agile Architecture?

What?


Why?


The main concept that stays behind Agile Architecture is:
 “Bring agility to architecture”
 “Bring architecture into the Agile world”
Most Agile teams
believe that an
Architect is not
required
There are two major problems when we adopt Agile methodologies and bring them into our
environment:
 Agile assumes that a software needs to be developed
 Agile assumes that we have a sort of control on how the system is and will be built
How?

First of all we should be able to keep our agility while staying focus on the main picture, by
bringing architecture into agile and vice-versa

6. Agile Architecture key objectives
Also Agile Architecture has its own key objectives:

Deliver working solutions (a Diagram is not a working solution …)

Maximize Stakeholders’ values

Find a solution that meets the goals of all the Stakeholder

Enable the next effort

Being able to Manage changes and complexity

7. Agile Architecture principles
 Value
People
 Communicate
 Less
is more
 Embrace
 Choose
 Deliver
 Model
changes: plan and deliver
the right solution for the Enterprise, not for your User Story
quality
and documentation in an Agile fashion

8. User Story

What is a User Story?

How can we add details to a User Story?

How you estimate a User Story?

Pitfalls of a User Story

9. What is a User Story?

User stories are short, simple description of a feature told from the perspective of the
person who desires the new capability, usually a user or customer of the system.
They typically follow a simple template:

“As a user, I can buy and sell stocks that are in my portfolio”

“As a portfolio manager user, I can act on portfolios for which I have permissions”

“As a user, I can reports that analyze my portfolios’ status”

10. As a USER, I can buy
and sell
STOCKS in my
Portfolio

11. How can we add details to a User Story?
Details can be added to user stories in two ways:


By splitting a user story into multiple, smaller user stories.
By adding “conditions of satisfaction.”
“When a relatively large story is split into multiple, smaller agile user stories, it is natural
to assume that detail has been added. After all, more has been written”
“The conditions of satisfaction is simply a high-level acceptance test that will be true
after the agile user story is complete”

12. User Story estimation
Pending
As a USER, I can buy
and sell
STOCKS in my
Portfolio
As a USER, I can buy
and sell
STOCKS in my
Portfolio
As a USER, I can buy
and sell
STOCKS in my
Portfolio
…
User
auth.
Port.
Mgmt
Docu
ment.
Stock
Search
Buy
mech.
Test
QA
2
4
8
16

13. What are the pitfalls of a User Story?

Even the best written user story leave room for interpretation and interpretation is not
design

Design is bring to the stakeholder when it’s ready and that’s the first time the
Stakeholder can start to ask for changes

The format of the user story is too agnostic. “As a User …”: which, how, when?

Sometimes stories become very big and the whole architecture is described in the
story details.

Unfortunately a User Story is not a technical document and it should not replace it

14. Common Estimation Mistakes

Don’t use Fibonacci, use the technique that fits your team (i.e. Power of 2 scale)

4 Values are more than enough to estimate a story

Define a size scale and stick on that

Vote independently

Always over estimate, never underestimate cause you will always forget about a
requirement or impediment

No laptops/tablets and ask for participation

15. Views and Viewpoints

Definitions

Different Views for different audience

16. Definition

An Architecture View is


“Architecture views are representations of the overall architecture that are meaningful to one or
more stakeholders in the system”
An Architecture Viewpoint is

“A Viewpoint is an abstract model that can describe part of a View or a View in a specific context”
So in essence each viewpoint is an abstract model of how all the
stakeholders of a particular type see the overall system

17. Architecture Views and Viewpoints
This is what most of the Stakeholders will understand

18. Architecture Views and Viewpoints
This is what most of the Developers will understand

19. Merge Architecture into Agile

20. Some Numbers - ROI

Return of Investment

” The term "return on investment" (ROI) is frequently used to describe the benefit derived

Formula:

ROI = (V1 – V0)
_____________
I

V0 Initial Value

V1 Later Value

I Capital invested




Example:
 Team cost (month): 50,000 $
 Current rev.: 300,000 $
 Estimated: 550,000 $
 Project est. : 26
 Team Velocity (be-week): 5
Result:
(550,000 – 300,000) / ((26/5*2)/4.5 *
50,000)
26/5*2 = num of weeks
/ 4.5 = num of months
211% we spend 115K but gain 250K

21. The estimation game

Provide to an Agile Team few stories in the form of Comics

Provide a simple View of the Architecture

Ask the teams to use a common estimation scale

Give two hours to provide viewpoints with estimation on it

22. An effective estimation technique

23. TOGAF and estimation
PHASE A
LEARNING
EXPERTISE
ALGHORIT.
PHASE
C
PHASE D
PHASE E
PHASE F
PHASE G
PHASE H
Vision
GUESSING
PHASE B
Business
System
Technology
Opport.
Migration
Govern.
Change
Mgmt

24. SCRUM and estimation