Presentation
- Whoami
- http://ua.linkedin.com/in/sergeyprokhorenko
- Head of head of Agile Practice at Luxsoft
- Since 2005
- 15+ customers
- 50+ ongoing projects
- 700+ Agile practitioners
- 100+ Certified Scrum Masters
- 15+ internal Agile Coaches
- Agile as a silver bullet
- Agile Providers vs Client problem
- Business value driven prioritization to deal with Always late with the things we really need
- Pay for DONE to deal with Paying for the wrong things
- Change without penalty to deal with Too expensive to make even little changes
- Client is in full control of the project to deal with Difficult to understand where we are right now
- Actual use of requested features
- Always 7%
- Often 13%
- Sometimes 16%
- Rarely 19%
- Never 45%
- Source: The CHAOS Manifesto, The Standish Group, 2011
- Simple rules
- RUP Referece and certification guide - 289 pages
- SCRUM Guide - 16 pages
- presentation slide 4
- Scrum is a game of chess - simple rules - but endless combinations
- idealized role of PO in a company
- Responsible for maximizing the value of the product and the work of the Development Team
- Sole person responsible for managing the Product Backlog
- Power
- Expertise
- Dedication
- Does Sprint Planning and PBR with the Development Team
- Tracks total work remaining at least every Sprint Review
- Real life PO example - a team of PO
- presentation slide 7
- End users / stakeholders - Product vision team - prototypes - PO - pPOs for teams.
- several PO - customer side PO, user side PO, intermediate pPO.
- customers are on the "other side"
- there are different time zones - 8hrs turnaround to get a solution
- product owner is involved either in business, or in PO activities.
- SCRUM becomes a cargo cult - doing SCRUM for SCRUM sake - no results.
- things don't happen
- How did we end like this? presentation slide 10
- Agile Providers vs Client problem
- Sprint level visualization
- SCUM rules - describe moves & technics, but not the strategy.
- What to do on the higher level to sync teams is left in the "grey", "dead" zone
- Management
- Are we on track to deliver scope on time?
- When release epics will be ready and what is the current status?
- What are PO (BA, pPO) doing? Do they have blockers?
- How many stories are ready for the next sprint?
- Are we ready for the next release planning?
- Developers
- What is the goal of the current release?
- Are we on the track to deliver on time?
- What are other teams doing?
- Are there any dependencies on a project level?
- Does PO and BA have enough requirements? - what would we do, when this sprint ends?
- Management
- What to do on the higher level to sync teams is left in the "grey", "dead" zone
- SCUM rules - describe moves & technics, but not the strategy.
- What can we do about it?
- People and interactions!
- Who is PO?
- man from business - no time for team - BETTER - can at least explain something.
- man from IT - no time for business.
- Clear roles and Responsibilities of dedicated PO on/from customer side
- Prioritization - only PO can do. If PO can't do - SCRUM wont live on
- Expertise - we can live with it. At least PO will understand business globally and get priorities.
- we can get external experts to help with
- Communication
- first in a list to save time on.
- least important - can gather once in a week to work.
- Who is PO?
- Processes and tools
- Use Kanban on high level at Project (program) level (presentation slide 18)
- Goals / epics
- Analysis ongoing
- Ready for Development
- Next 20 stories to pick
- InDev
- Acceptance OnGoing
- Ready for production
- High level flow
- Request from stakeholders
- Backlog prioritization
- Backlog refinement
- Ready for development
- Sprint
- Ready for release
- Value stream mapping
- Request from business sponsors
- Program initiation <- involve / add team here!!!
- Project chartering
- Epics breakdown
- User story drafting
- User story grooming <- if team joins here - you will get waterfall
- Ready for spring
- In development
- Ready for demo
- Ready for UAT
- in UAT
- Ready for release.
- Backog prioretization
- +Addons
- sign off
- release publishing
- Use Kanban on high level at Project (program) level (presentation slide 18)
- DoD Agreements (Definitions of Ready) (Analysis phases)
get more detailed on each phase- Do not build a formal contract, but rather visualize as much as possible for sprint.
- Finishing of ready. (FoR)
- Program initiation
- PID is shared with BAs
- Project charter is drafted and shared with business sponsors and BAs
- Project chartering
- Charter is approved by business sponsors
- Final charter is reviewed with BAs in a meeting
- Epics breakdown
- Charter breakdown into epics is approved by PO
- All epics are described in Confluence with:
- Business context
- Problem statement
- High-level acceptance criteria
- All epics are presented to the team(s)
- Epics are included into backlog and prioritized
- Business contacts identified
- User story drafting
- User story is well-analyzed by BA and conform to INVEST criteria
- https://en.wikipedia.org/wiki/INVEST_%28mnemonic%29
- Detailed BDD scenarios are created
- Mockups are created (where applicable)
- Data requirements specified (if any)
- Business logic is specified (if any)
- US reviewed with business SME
- Acceptance criteria are reviewed by business SME
- US is prioritized in backlog and priority approved by PO
- User story is well-analyzed by BA and conform to INVEST criteria
- User story grooming
- Team reviewed and agreed that US conforms to INVEST criteria
- BDD acceptance scenarios are well understood by team and approved by business
- All research spikes identified and completed
- US breakdown is approved by team (and re-approved by business if any changes)
- Business contacts are shared with the team
- Design is approved
- DoD for last analysis phase = DoR for sprint
- Limit WIP for BAs - not more than one Epic. Only 30% value added as they work on several projects
- Backlog grooming Ground Rules
- Regular
- At lease once a week, scheduled with PO
- Started upfront (at least a week before planning)
- Timeboxed
- 15-20 min per story
- If timebox isn't enough - go offline and prepare for next session
- Includes the whole team
- All team members ask questions upfront
- Team members (not only PO/pPO) describe story value and scenarios
- Strict DoD
- If artifact doesn’t follow agreed DoD it isn’t moved to the next phase
- Regular
- Effective collaboration
- Feature team US - Scrum of Scrums - Feature team UA
- Scrum of Scrums
- Cross-functional teams
- Single backlog with unified estimates
- Single Product Owner for the whole backlog.
- Proxy Product Owners for each location #TBD - feedback loop
- Joint release planning
- SCRUM of SCRUMs = Big picture of the project
- Anything depends on everything. SCRUM as a mirror of the processes.
- also as a feedback to management
- Inspect and adapt
- People and interactions!
- Product vision and goals. Sprint Zero Workshop
- Who needs it most?
- Scrum Team
- Product owner
- Scrum Master
- Gathered all together in the same place
- How long it takes?
- one - two weeks
- What do we get from it?
- Synchronize product vision - get same language
- Establish long term goals
- Get Shared understanding of business
- A common training and common language for the team
- How do we do it?
- Synchronize the product vision between the stakeholders (business canvas)
- why do we need this product?
- what problem does it solve?
- who are the users - what are their problems?
- what this product can do you can't do with other tools?
- if you automatise something existing- how better the life would be with this product?
- The goal is to get to a point, where team get a first hands on the product vision
- Business model canvas as a tool
- Obtain Goals
- Create middle-term goals for the close half year. Some examples are:
- get userbase
- get to some minimal functionality
- if it is an internal product - create SMART (measurable) goals (70% of manual activity to automatize)
- get to understand - how do we measure success/failure
- Create middle-term goals for the close half year. Some examples are:
- Create user personas for story mapping
- Go for Story mapping.
- Story mapping is created from the system users (persona's) point of view
- Create a separate storymap for each user
- as a user ... (persona from previous step)
- I would like to do ...
- so I would achieve ...
- Use different coloured stickers for different personas - the one who needs the story - gets it
- We must create complete story
- either for one user
- or for single process
- Storymap becomes first backlog draft
- Add weight for each story (can use fibonacci numbers as indicative weight) - affinity estimation
- if some stories are over some measure in points - they are key target for splitting or lower priority
- Slice user stories
- Establish DoD (definition of done), Acceptance criteria
- unit tests
- introduction
- testing
- Set Priorities
- Formulate Sprint 1 from stories (half sprint or quarter - better as they tend to grow ;)
- Agree on working agreements (DoD partially, DoR (definition of ready) for requirements, Sprint pulse (timings)
- Synchronize the product vision between the stakeholders (business canvas)
- Who needs it most?
- Recommended literature
- Implementing Lean software development
- Lean from the trenches
- Scaling lean and agile development
- Practices for Scaling lean and agile development
User story mapping is a visual exercise that helps product managers and their development teams define the work that will create the most delightful user experience. By visually mapping out these user stories, product teams tell the story of the customer journey and break it into parts. You may find tools and templates to creating user story mapping in Creately software.
ReplyDelete