More Related Content Similar to How can you keep the customer inputs flowing, the teams running and still know where you stand? (20) More from AgileSparks (20) How can you keep the customer inputs flowing, the teams running and still know where you stand?1. How Can You Keep The Customer
Inputs Flowing, The Teams
Running And Still Know
Where You Stand?
Naama Gafni Lifshitz,
SAP Labs IL
2. Introduction
SAP Scrum and Lean implementation
Multiple teams cross locations
Taking the methodology into daily
practice
© 2012 SAP AG. All rights reserved. 2
3. Product Owner Role
Customers Product
Users Teams
Stakeholders Owner
Product Analysis &
Execution
Inputs Insights
© 2012 SAP AG. All rights reserved. 3
4. Inputs Flow
Processes and PO Deliverables
User Release
Design
Story Backlog Execution
Thinking
Mapping Grooming
Vision Scenario Estimated Sprint backlog
Personas User stories User stories Ranking
PoC HL Priorities Priorities
Mockup Release plan Completed
stories
© 2012 SAP AG. All rights reserved. 4
5. The Traditional Backlog
Long
Missing big picture
Is not scenario oriented
Minimal scope
Communication tool?!
© 2012 SAP AG. All rights reserved. 5
6. User Story What?!
A 2 dimensional map of the
What product, driven by a user scenario
and ordered by priorities
When 1-2 days at the beginning of the
release planning
Who Done by a group multidisciplinary
team members
© 2012 SAP AG. All rights reserved. 6
7. User Story Map
Usage Sequence = Scenario
Personas Usage Sequence
High Level User Stories
© 2012 SAP AG. All rights reserved. 7
9. User Story Map - Example
Setup Request Approve
Users Review Approve Reject
Admin mgmt. request request request
Create Submit Get
Employee status
request request
Add Via Via Via
user Web Web Web
Edit Via Via Via Via Via
user Mobile Mobile Mobile Mobile Mobile
Remove Via Via Via Via
user Email Email Web Web
© 2012 SAP AG. All rights reserved. 9
10. User Story Map Benefits
Improves backlog quality
Focus on end-to-end customer Scenario
Easy to create
Visualizes the release backlog
Validation with customers
Enables Big picture communication with team
Can be used to track progress
Source: Jeff Patton www.AgileProductDesign.com
© 2012 SAP AG. All rights reserved. 10
11. Inputs Flow
Processes and PO Deliverables
User Release
Design
Story Backlog Execution
Thinking
Mapping Grooming
Sprint backlog
Ranking
© 2012 SAP AG. All rights reserved. 11
12. Defining a Ready Criteria
READY is when the team says: “Ah, we get it”.
Must have Desirable
“What” and “Why” are Mockups ready
clear
Testing strategy
User stories are reviewed
Reviewed strings
and fit in sprint
Dependencies are identified
User stories are ranked
© 2011 SAP AG. All rights reserved. 12
13. The Planning Problem
Coordinating user stories across multiple
teams is hard
PO is overloaded and needs to prepare
for planning day
User stories not always accepted by the
teams
Planning meetings can be long and
ineffective
© 2012 SAP AG. All rights reserved. 13
14. Pre-Planning Per Team
– NOT A One Man Show
PO
UX KS
PO
Developer/ Architect
Scrum Master
© 2012 SAP AG. All rights reserved. 14
16. Pre-Planning Process Phases
Phase 2
Planning
Planning
Phase 1 Phase 3
Detailed
Day
Day
Scoping Finalization
Definition
POs POs POs POs POs POs
Sync Sync Sync Sync Sync Sync
Product Status Review
Sniffing
© 2011 SAP AG. All rights reserved. 16
17. Pre-Planning Benefits
Easy to establish
Shortens planning day
Increases team effectiveness during sprint
execution
Early engagement of multidisciplinary team
Risks emerge early
Maintains the flow of the team activities
Gives structure for multiple team planning
© 2011 SAP AG. All rights reserved. 17
18. The Product Team
Chief PO Team POs
PMO UX Lead Chief Architect Quality Lead
© 2012 SAP AG. All rights reserved. 18
Editor's Notes Is long and hard to manageDoes not show “big picture”Is not scenario orientedHard to define minimal scopeCannot be used as a communication tool with customer and teams 2 dimensions: User: typical users = personasUsage: what the users do with the software = usage sequenceInner structure reflects a “day in a life of a persona” = backboneBased on the backbone, you derive the user stories for the backlog 2 dimensions: User: typical users = personasUsage: what the users do with the software = usage sequenceInner structure reflects a “day in a life of a persona” = backboneBased on the backbone, you derive the user stories for the backlog