Stories are the Fundamental unit of work in an agile project, which “describes some item of value to a user or product owner”. Stories are units of value that and are visible and understandable outside the team. Stories can describe functional scenarios, interactions, UI screen, and non functional requirements.
We use stories to drive the team’s work effort. In scrum, stories are prioritized by the Product Owner. The stories are then broken down into tasks by the team. Stories are also know as backlog items in scrum.
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.
Choose:
- The PO says go.
- The Teams says they are ready.
- The SM has determined a time box for the sprint.
- The team and PO agree to a time box
- The PO understands and is prepared to talk about the stories
Comment: There are a number of things you should do before you can even begin planning. The most important thing you can do is make sure that your Product Owner is prepared, and understands what the stories are about. Remember that the Product Owner is a role here, so what we’re actually saying is that someone on the Team knows about each story; that is, each story has its own champion (Story Owner) who represents the Stakeholder’s needs/wants to the Team. This may require that the Product Owner (person) coordinates the
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”.
Stories are the Fundamental unit of work in an agile project, which “describes some item of value to a user or product owner”. Stories are units of value that and are visible and understandable outside the team. Stories can describe functional scenarios, interactions, UI screen, and non functional requirements.
