What is agile analysis?
Simple put, “finding the stories anyway you can”.
Analysis is classically defined in the dictionary as breaking something down
into it’s component parts or pieces. We will explore a different definition of analysis so that it supports the notion of agile / scrum product development.
Analysis is finding an opportunity to proceed and agile analysis is finding those opportunities any way you can. Typically in agile we use stories as the fundamental element in analysis. We use stories as a way to drive the team or channel the teams effort toward desired outcomes. In scrum, stories are prioritized by the Product Owner who may or may not have found them.
When we do agile analysis we are finding these stories anyway we can. The goal is to cause movement. Movement from the team will reveal issues, realities and impediments faster. The more complex a problem then the more we are looking for ways to move which will allow us to explore the problem from other angels. The exploration of a problem space is analysis and it often yields more opportunities to stories. There are many techniques we can use to find stories (i.e. Use Cases, CVA, User Roles, Themes, Epics etc).
For more on this contact us for our white paper or take our training course on Agile Analysis.
This term is defined within the context of story driven work. Story driven work can be done in any agile method but, is commonly used in Scrum.
To find the stories anyway possible. There is no presumption that one form of analysis is better than another. The goal is to find the stories so that we can drive the team in bite sized chunks of work.
Agile Analysis can be be done with any technique and might include but, should not be limited to.
- Use Case Analysis
- Commonality Variability Analysis
- Financial Analysis
- Market Research
- Simple dialog (ask your customers)
- Simple dialog (ask your stakeholders)
- JAD sessions
- Interactive techniques (i.e. Innovation Games)
However, you find the stories they are opportunities to proceed. With good opportunities you have a chance to move understanding forward.
Complex work requires an adaptive approach to analysis.
Planning |
Posted by The 3Back Team
Jan
18
2010
Choose:
A placeholder story is a sign of sloppy planning- All work should be known ahead of time and planned during sprint planning
- Yes, this allows the Product Owner to dump things into the sprint as needed.
- Sometimes we have a history of unexpected bugs/issues of handle it now. This allows us to track how much of that is showing up and leave some slack for when it does.
- We often have work we know we will have to do but, don’t know what it is yet.
Comment: This is a way to track how much unknown work is showing up and manage the amount by triggering a conversation when needed. One of the most common issues for scrum teams is what to do about work that we expect to have to do during a Sprint, but don’t actually know the details about yet, such as bugs we have to fix in existing systems, or expected sales support efforts. Using Place holder stories is a a method to manage these “known unknowns”.
into it’s component parts or pieces. We will explore a different definition of analysis so that it supports the notion of agile / scrum product development.
