Sgin2013 scrum accompllished-whatandwhat not!- apo-introspects-angelineagarwal

Angeline Aggarwal, CSPO

Product Owner, Tata Consultancy Services

Scrum Gathering India Regional 2013

July, 2013 : +91 99201 37484

: [email protected]

What and What NOT! - A PO Introspects

mailto:[email protected]

2

A Product Owner is born!

Developer for 7 years

Working on RAD methodology; accustomed to

quick turn-around times.

Suddenly Agile – Alice in Wonderland!

One-week sprints were being followed

enterprise wide – Hit the ground running!

In this presentation……

Scrum flow reviewed

At each step identify

Common mistakes a beginner

makes

How they impact the end

result

How to avoid / become better

ENVISION 1

4 Introspection by Angeline Aggarwal

A vision must be detailed enough to provide clarity…

Why have a vision?

Guides the team and describes the

essence of the project

Provides clarity to the stakeholders

that the team has understood what

they have to do!

Attributes of a good vision

Other Attributes

Stable

Clear

Appealing

Broad

Short

Pass the elevator test

Demystify the WHO, the WHAT, the

WHY and the HOW

Who are our customers

What do they need

Why do they need

How we can meet the needs


But “Vision” for my first project was woefully incomplete!

Vision for the my first scrum project

To make all finance system applications compliant with new firm wide change

My Scorecard:

Attributes Score What's the problem?

Who is the

stakeholder POOR

Team does not know who to turn to, if we run into impediments and

feedback

What are the

customer needs POOR Unclear: Left open-ended with a catch-all "ALL" systems compliant

Why does the

customer need it POOR Not identified: Team can't identify with the customers needs

What is the target

time-frame POOR

Not stated: How do we figure out what resources/time are required and

how much time will be required

Stable POOR The client can go on making continuous changes

Clear POOR Scope left unclear

Short GOOD But its too short, doesn’t cover even the essentials

Broad GOOD Its TOO broad and left open-ended

Engaging POOR Only because it is short


This is what the ‘Vision’ should have looked like

Revised Vision

Statement Description

Problem/Opportunity

Statement

Customer is implementing a new length of employee ids to cater to influx of

new hires

All downstream applications may not support the increased length

Potential Solution Test critical applications

Identify issues

Fix issues to make the application compliant

Scope of the project To identify list critical applications which do not have an development team

Applications which are not to be decommissioned in the next one year

Who is the

stakeholder/Customer

Program managers (indentified people) for portfolio of applications

Value to the customer New hires would be able to use applications error free

Timeline 6 months

Success Criteria Applications should support new length of person id

While it is not short, it is crisp and contains all the relevant information


What went wrong

No clarity on scope / interim

changes

Not knowing who is involved and in

what capacity

Not having asked the right questions

Impact

Improper prioritization of the

requirements/backlog

Slow the pace in removing

impediments, getting approvals,

requirement clarifications

Doing it right…

Ask: The more you ask the more you understand. But ask the right questions

What is more critical

What needs will it address for the user

Share the vision with the entire team and make sure the entire team has the

same understanding

Engage with the sponsor: With the right person at the right time will help in

proper planning and removing most of your impediments in next steps

‘Vision’ - Recap

CREATE A BACKLOG 2


Step 2: Creating a backlog consisting of epics and stories

The product owner translates the

vision into a backlog

Product backlog contains the

following:

o Themes/Epics/Stories,

Technical work and defects.

Attributes of a good Product Backlog

D E E P

Detailed Appropriately

Emergent

Estimated

Prioritized

Visible: Readily available to the

team and stakeholders

What is the backlog


How I created my first backlog

In my project:

Each application became an ‘Epic’

Disregarded the Iceberg: Aiming to break down all the ‘Epics’ into

detailed ‘Stories’ to get to know the overall size of the project

(Waterfall mindset) - Spent two sprints breaking down half the sprints before

checking course

Two types of stories

Standard setup stories common for all applications

Application Specific Stories

Started implementation of set up stories for couple of applications and

staffed with team

Project was set up in ‘Mingle’


A backlog in disarray

0 1 2 3 4 5 6 7 8-10 11+

Set up

Mingle

Get

Access

App_1

to 10

App_1

Demo

App_1

Story_1

and 2

App_2

Analyz

e Code

App_2

Confir

m

change

s with

User

App_2

Code

changes

. . .

App_2 –

Identify

Testing

Strategy

App_2

-

Testing

App_2 –

Testing

interfaces

(Dependency

came up)

Get

info

App_1

to App

10

Staff

Team

App_1

and

App_2

App_1

Analyze

code

App_2

Demo

and

Analyze

Code

[App_1

contin

ued on

track]

Adhoc

Develo

pment

work

(Added

subseq

uently)

. . . . .

Adhoc

Development

work (Added

subsequently)

. . .


Backlog: What was wrong and what was the impact

Incorrect Prioritization: Too much upfront effort adding details to ‘Epics’ to be taken up much later

Impact: Effort wasted and re-planning required, big picture missed due to ‘too many items’

Activity specific sprints: Application 2 was proceeding like a waterfall model within the agile framework

Impact: Idle time- Developer idle due to delay from user. No back up work planned

Interdependencies of applications overlooked:

Impact: Unforeseen delays due to dependencies on teams handling other application

Ineffective Planning: Should have identified testing strategy upfront

Impact: Emergency changes in release planning

Adhoc development work added to backlog – Team ‘Vision’ was compromised. Cascaded into multiple

change requests and additional work

Impact: Huge delay. Initial user estimate of 2 months took 3 months despite overworked team

Neglect backlog Grooming: Specific time not allocated for backlog grooming

Impact: Could not eliminate unwanted items prior to sprint – backlog not ready for next sprint –

resulting in confusion for the team

Overall impact:

Non shippable deliverables per sprint

No sign off from the customer

Overall release getting delayed by 3 months


Backlog: Lessons learnt

Prioritization

Take up application with most dependencies initially

Progressively refine – Impossible to think of everything upfront

Add details Just-In-Time, not weeks in advance because things

change as new information emerges

Helps avoid too many backlog items

Stick to the vision:

Any adhoc requests not in line with project vision should be treated

like a separate project – with its own backlog and stories

Backlog Grooming

Would have set aside Time-boxed period for the entire team to

focus on cleaning up the backlog

ESTIMATE 3


Estimation 101

The process of quantifying the effort

required in story points or ideal days

involved in implementing the Product

Backlog with the resources available

What is Estimation

The WHEN, WHO And HOW of Estimation

The When:

Before the first sprint

During the first 2 sprints

On going

Who: Product Owner + Scrum Master + Team

The How

Story points vs. ideal days

Planning poker

End Result

Sized Stories

Results in backlog refinement


What were the mistakes Impact How to avoid them

Playing the task master:

• Product owner drives estimate

based on deadline of the

project

• Team estimated 3 weeks I

pushed for 2. It finally took 3

weeks

• OR Team compromises on

Quality

Estimate should be Honest not

influenced:

• Developer should give the

estimate not the product owner

• Scrum master to facilitate

Equating story points to days:

• Each story is considered

individually rather than a

collection to relative estimate

• Failed to see big picture

• Overall deadline slippages •Play the poker - Its fun!

Trying to estimate the

inestimable!

• Stories are too complex or too

many unknowns/dependencies

to estimate

• Radically different estimates

from team members due to

different interpretations

• Extended planning duration

• Stop and think and break down

further

lUnclear Scale:

lTeam not clear on the scale

being used

• Use a scale which all team

members identify with

• Identify smallest and largest at 2

points and 20 points respectively

Chasing Velocity:

Adjusting estimate to meet

forecasted velocity

• Slippages across sprint

deadlines

• Over-worked team –

unsustainable in the long run

• Velocity gets derived from the

estimates and not the other way

around

Common pitfalls and how to avoid them


POs - do not influence the team

USER STORIES EXAMPLES 4


Backlog consists of multiple USER stories

Defining the deliverables from a users perspective aligns with goal of the product

Format: As a <USER>, I want <SOMETHING>, so that <SOME VALUE>

o For Technical stories, user is replaced by the module

Define from a “USERS” perspective

Attributes of a good Story

I N V E S T

Independent

Negotiable

Valuable

Estimable

Small

Testable

Should define the WHO, WHAT and WHY

Story should contain acceptable criteria (for validation) - Sufficient to define

the boundaries of the story


Its time to write a story: User Story 1

User Story:

Add a share activity

section to the share

activity report to display

share transactions for a

user

Acceptance criteria:

Display share activity

information in the

following columns, no of

shares, date, activity (Buy

or sell), quantity, value

per share and total amount

User Story:

As a user, I want to see the share

activity details, for the selected

person for the current financial

year, so that I may view the

details of the share transacted

by that user and compute share

balance


Display share sale and share

purchase in separate rows with

the following information, no of

shares, date, activity (Buy or

sell), quantity, value per share

and total amount in a user

defined format

Should have

been


What were the mistakes Impact How to avoid

mistakes

The

“WHY” is

missing

Story defined from a

developers perspective of what

needs to be done, not the why

Impact: If we knew what we

wanted to use the report for,

we could have added additional

data useful for user (like total

gain in the period, etc)

Could have suggested

displays with additional

data would could have been

meaningful to the user

Potential Additional

revenue lost?

Ask more

questions with

the

stakeholder

and constantly

engage

The WHAT

not

completely

defined

Report pertains to which year –

what test data to retrieve

NOT testable. Boundary

condition missed out.

Involve the

team in story

writing

Not

negotiable

User wanted a different format

for a boundary condition

(shares bought and sold on the

same date in separate columns)

Could not be completed in

simple sprint.

Code had to be re-worked.

Few person days additional

required

Describe by

examples

User could

have pointed

what he

wanted

Analysis of User Story 1


Story..continued..: User Story 2

User Story:

As a user, I want to run the

report X for multiple

employees in a given date

range


Report should accept

multiple employee

numbers in a comma or

space separated string

User should be able to

enter start and end date

User Story:

As a user, I want to run the

report X for multiple employees in

a given date range so as to be

able to generate a batch of

reports of all employees under a

partner at one time


Report should accept multiple

employee numbers with a

minimum of 750 in a comma or

space separated string

User should be able to enter

start and end date

The entire report should be

generated in a maximum of 30

seconds

Should have

been


What were the mistakes Impact How to avoid

mistakes

The

“WHY” is

missing

Lead to unclear boundary

condition below Focus on

discussion

rather than

documentation:

Ask more

questions and

constantly

engage with the

user

ilities and

UI

constraints

Boundary condition not

defined:

User wanted to run report for a

minimum of 750 users at one go

Performance tuning

(optimization) was not

done

Architecture reworked for

optimized performance

Missing

definition

of done

How long should the report

generation take was not listed

The entire report could

not be done in 30 secs as

required by the user, had

to increased up to 2 mins

Analysis of User Story 2

Is it possible to write a complete story upfront and ready for a sprint - NO

ALL ABOUT THE SPRINT 5


Sprint away!

A time-boxed period during which the scrum team works to build a potentially

shippable increment to the product

Both incremental and iterative at the same time

Iterative - Planning + Execution + Review

End result: Potentially shippable increment to the project / product

Deliver at end of each sprint: Allows to inspect and seek constructive feedback

SPRINT PLANNING 6


What is Sprint Planning

Entire team (Product Owner, Scrum

Master, Developers, etc) participate in

the Sprint planning meeting to discuss

the following

Sprint goals

Selection of sprint backlog for the next

sprint (Backlog items that the team

commits to and the tasks they are

broken down into)

Typical effort of two-four hours per

sprint

What happens during Sprint Planning

Outcome of Sprint Planning

Defining what the team will achieve in the next

sprint

Shippable increments

Behind-the-scenes features

Just something valuable

Further break down stories based on new details

Emergent requirements


Sprint Planning Case Study

Top Story Priorities

Stories Points

App_2 Testing (Modules 01 to 10) 3



Test App_2 Interface 1 5

Test App_2 Interface 2 5

Capital Tax Report

(became a 20 pointer

subsequently)

8

App_3 Analyze Code Base 3

App_3 Get Access to Dev Env. 2

App2_Analyze Back end 3

App3_Analyze Import Module 3

App3_Upload 2

App3_Sumbit 3

Chasing too

many points

per sprint

Interface

modules should

have been

prioritized over

• Story too big

to be taken

up and

therefore

broken down

• Task based

break down

into :

Analyze the

requirement,

etc

Detailed plan

for all the

activities put in

place much in

advance


Sprint Planning Mistakes Impact How to avoid mistakes

Lacking the big Picture:

• Selecting stories with a

short term goal in mind

• In-correct prioritization

and thereby selection of

sprint

• Start with a prioritized backlog

• Always first take stories which

have maximum

interdependency

Waterfall in Agile

• Planning activity specific

sprints rather than holistic

development of an

increment

• No user specific

deliverable

• Risk of spending too

much time for one

activity which doesn’t

get validated

• AVOID the temptation and

ALWAYS deliver at-least a

testable increment

Chasing Velocity

• Over-committing or

selecting stories that are

too large for the sprint

Planning for overwork

“Need to complete at least

14 story points to maintain

our velocity”

• Overworked team

• Compromise on testing

and quality OR

• Under deliver in next

sprint

• Plan based on what can be

completed end to end

• Selecting the right mix of

stories – not all large, not all

small

• Achievement is not in terms of

velocity – velocity should result

from doing scrum right

Planning for a better finish


Sprint Planning Mistakes Impact How to avoid mistakes

Scheduling issues

• PO/ Team member is not

available for the

meeting

• Team members

don’t understand

the sprint goals

• Be flexible with scheduling

• Make the planning meeting

compulsory to all

lPlanning too much into

the future

• Little room for

progressive

adjustments,

• Leads to effort

waste

• Product Owners! Know your backlog

• Plan at the optimal time – one or two

sprints in advance

Starting the new sprint

with planning

• Should be done 2 days

before next sprint starts

• Result in idle team

• Lead time to get

At least 5-10% of team time should be

reserved for planning for the next

sprint

Ignoring Team Ability /

Availability

• Leads to over

committing and

under-delivering

• Avoid assigning story to individuals,

assign story to a team / sub team

• Opt for pair programming where-ever

critical

• Product owner should be aware of

team absences and take that into

account

Think holistically – don’t lose track of the overall vision

SPRINT EXECUTION 6


Are we getting there? Can you see the goal?

Team works on the backlog items

committed for the sprint

Mode of operation:

Time-boxed daily scrum

Task boards

Impediments list

Changes in boundary conditions –

decide on whether to terminate

the sprint


Sprint Execution

Mistakes Impact How to avoid mistakes

No daily scrum

• Inconsistent meeting

times

• Skipped meetings

• Difficult to understand team

progress

• Individual follow up with team

members – waste of time.

• Team unaware of each others

work and possible impact to

their story

• Disciplined daily scrum

• Fixed meeting time and place

Lack of enthusiasm

• Team not fully

involved

• Meetings from their

desk /

simultaneously doing

other work

• Loose an opportunity to see

overall progress, give and

receive inputs

• Just focused on status updates

• Daily Stand-up done right!

• Time-boxed no lengthy

discussions

• Accounting for time

during DSM rather

than goals and

achievements

• Developer may have spent a

day on the story but achieved

nothing in terms of value

• Updates should be in terms of

what was done and not how

much time was spent on it

Sprinting away from the goal and how to avoid it


Sprint Execution

Mistakes Impact How to avoid mistakes

No mid sprint checks

• Items left for

implementing at the

end – not mid-sprint

checks

• Compromised on scope and

quality

• Maintain Sprint Burn down chart

• Not a time for troubleshooting

• Reduce wasteful effort –

automate where possible

• Don’t leave testing for the end –

it generally gets skipped

• Changing the sprint

goal/sprint backlog

during the sprint

• Hampers the team’s focus

and rhythm

• Leads to hasty and

unplanned activity

• Avoid changes to the sprint goal –

what to do if the priority of

backlog suddenly changes?

lImpediments

• Not raising / handling

impediments

• Delays

• wasted effort

• Slippages

• PO should follow up / force /

beg for team to come up with

impediments

• Make the team comfortable to

escalate issues

Sprinting away from the goal and how to avoid it

REVIEWS AND

RESTROSPECTIVES 6


A great finish! – Reviews and Retrospectives

Objectives of the Sprint Review

1 hour per sprint: Set aside to reflect on

the sprint gone by

Start, Stop, Change, Continue

Setup and continually improve best

practices

No retrospective

A missed opportunity to learn

Repeat the same mistakes

Keep it informal

10-15 mins per Sprint to Inspect and Adapt

Highlight team goals and achievements

Assess the achievements against the sprint

goal and not just completion of backlog

A natural end to the sprint, not a

distraction requiring preparation time Retrospective: Learn from the past


Maintaining a sustainable pace of development

Pace yourself like a marathon runner;

Get a head start, go steady in between &

Towards the end, give it your all

Start Small but think Big – never forget the big picture

Use same length sprints - helps planning and the team works with Rhythm

Focus on delivery – Definition of done – complete story

Continuous improvement

Don’t bank on overtime – it cannot be sustained

Refine the plan – adjust to accommodate changes in scope, time

Never compromise on quality

Maintain agile discipline

APPENDIX 6


References

http://agile.dzone.com/news/retrospect-about-sprint

http://www.slideshare.net/Conscires/sprint-execution-standup-taskboard-etc

http://www.slideshare.net/romanpichler/product-backlog-tips-and-tricks

http://www.slideshare.net/dhaval.r.panchal/keeping-product-backlog-healthy

http://agilepainrelief.com/notesfromatooluser/2012/06/scrummaster-tales-learning-how-

to-estimate.html

http://colearningbe.wordpress.com/2013/04/01/most-common-mistakes-in-scrum-

ceremonies-27-estimating-stories/

http://scrummethodology.com/scrum-effort-estimation-and-story-points/

Websites

Book

‘Succeeding with Agile’ by Mike Cohn































http://agilepainrelief.com/notesfromatooluser/2012/06/scrummaster-tales-learning-how-to-estimate.html











http://colearningbe.wordpress.com/2013/04/01/most-common-mistakes-in-scrum-ceremonies-27-estimating-stories/




























Date post:	19-May-2015
Category:	Technology
Upload:	india-scrum-enthusiasts-community
View:	219 times
Download:	0 times

Sgin2013 scrum accompllished-whatandwhat not!- apo-introspects-angelineagarwal

Technology