Story Mapping and JIT Analysis
•Descargar como PPTX, PDF•
1 recomendación•752 vistas
Story maps can help prioritize product backlogs by providing more context than traditional lists. They visualize activities, tasks, and stories on a map to clearly show what is needed for minimum viable products and future releases. Just in time analysis uses simple, low-fidelity artifacts and conversations rather than extensive upfront documentation and analysis to support collaboration on large teams. Daily stand-ups, story mapping sessions, and ad-hoc discussions allow teams to analyze needs as they work rather than trying to anticipate all future questions.
Recomendados
Más contenido relacionado
Destacado
Destacado (10)
Último
Último (20)
Story Mapping and JIT Analysis
- 1. Story maps and just in time analysis Team GunFire @benmathews80
- 2. Product Backlog @benmathews80
- 3. Product Backlog Hard to prioritise One dimensional Can lack context Prone to gaps @benmathews80
- 4. Story maps What are those then? @benmathews80
- 6. Story maps Activity Sign in Task Register Log in Log out Can create a Can access Stories basic account secure page Can log out Email Can reset confirmation password Capture company Can see Capture Can see welcome name confirmation message @benmathews80
- 7. Story maps MVP Release 2 Release 3 @benmathews80
- 10. Story maps Reveal Helps slicing questions User focused Visual Aids prioritisation Show MVP clearly @benmathews80
- 11. Story maps Get the activity and task level right Explain to the team Work from the map @benmathews80
- 12. Just in time analysis (or how we’re coping with a big team) @benmathews80
- 13. JIT analysis I try to do no work… (but fail!) Team pulls analysis Simple artefacts are better A conversation is better still @benmathews80
- 14. JIT analysis Daily stand up Story PO catch huddles up Ad-hoc conversation Retrospective Backlog sessions @benmathews80
- 15. JIT analysis Lo-fi artefacts @benmathews80
- 17. @benmathews80
Notas del editor
- Huge array of stories of different sizesLittle traceability of stories that have been decomposedToo detailed to get an overview – lacks context - Hard to see gapsHard to prioritise “log in is just as important as register new user”
- Asking a product owner to prioritise some stories is meaningless to them. E.g. register vs log inAs we break large stories down, the resulting workable stories can lose context and obscure the bigger picture (smell – lots of stories with the same value statement)Hard to spot gaps where the stories meet, assumptions about where one story ends and another begins
- Tolkien produced a detailed map of Middle Earth to give readers context and to help visualise the journey the fellowship took.Story maps aim to do something similar for a project.Jeff Patton (circa 2005 although used before)
- Start with main activities – do this for all the activities in the systemIdentify the tasks the user does as part of that activityGenerate stories for those activitiesIdentify what stories are releasable and those that aren’tI’m never asking my PO to prioritise log in vs log out.
- Produced high level estimates based on the tasksStarted to build up a list of questions and risks
- Started to get estimates on the first release of storiesQuestions answered visibleString indicates MVP
- Our usual team size is 4 devs plus QA, PO, BA, SMThis project has 8 devs, bigger than recommended scrum size (12 people)Several apps, CRM, eCommerce, Fulfilment, Job Management, FinanceAcceptance criteria usually created in backlog session, too many people to manage that effectivelyProblems to solveHow do I know what people need to know? How do we share that information without making peoples heads explode?When do we capture acceptance criteria and who needs to know them?
- Touch points previously mentioned are opportunities to request informationFocus on simple documentation at the point at which it’s neededSpend more time making sure we have conversations. My mornings blocked out for huddles and sitting with pairs to see if they need anything.
- Backlog sessions now just about high level understanding of scope and sizing. Some technical discussion.PO catch ups make sure I’m in sync with the PORetrospectives (I didn’t understand…)Conversation during the day (co-location for the win)Story huddles – as story starts, dev pair, QA and BA discuss and write acceptance criteria.