- Story - Products features written from the perspectives of end users. A story typically follow a simple template: As a <type of user>, I want <some goal> so that <some reason>. See more about store example here.
- Spike - A special type of story that is used to drive out risk and uncertainty. A technical investigation to produce an answer in regards to some acceptance criteria on a Product Backlog Item (PBI).
- Defect - A misbehavior of the software.
- Product Backlog - Collection of user stories about product features. list of requirements for a product.user story - something that user want; work expressed in the backlog.
- Sprint - Short duration of milestone; manageable chunk of project; ship-ready release cycle; usually 2-30 days.
- Epic - A large user story; effort too huge to complete in a single sprint.
- Theme - A collection of user stories.
- Burndown Chart - Day-by-Day work remaining; monitors the progress of each release sprint;
- Burndown Velocity - The slope of the burn-down chart in hours/day.
- MoSCoW - A way of prioritize stories into must have, should have, could have, or won't have.
- SWAG - A scientific wild-ass guess (SWAG) is estimate in terms of assumptions and informal calculations.
- Product Owner - represent customers; helps make sure the right features make it into the product backlog, negotiate stories to be taken on in a sprint, order (not prioritize, see reference) product backlog items (PBIs), helps the direction of the product; represents users and customers of the product.
- Scrum Master - is similar to a project manager who makes sure project is progressing smoothly and members get their job done, sets up meeting, monitors works, facilitates release planning.
- Team Members/ Developers (development team) - size PBIs either in points or hours.
Share thoughts and concerns to understand the workflow.
A fast-pace standup meeting list the work, obstacle, solutions since the last meeting to keep the team in sync.
Sprint Planning Meeting
A meeting at the beginning of a sprint in which the Product Owner and the team negotiate which stories a team will tackle. To plan a release,
1. Start with product backlog to identify what user stories to put into a Release Backlog.
2. The team then estimate stories and Product Owner have user stories ordered in the Release Backlog to come up with a total amount of work to complete the release. To estimate user story, one approach is to adopt story points, another approach is to estimate in 1,2,4,8 hours, 2,3,5,10 days, 1,2,3,6 months. Estimate in between will fall into the next larger bucket.
3. Lastly, plan out several Sprints (2-12) for a given release. At the end of each sprint, have a Sprint Retrospective meeting to reflect and improve.
Sprint Review Meeting
At the end of a sprint, the team presents their work to the product owner who either accepts or rejects the work.
Sprint Retrospective Meeting
A meeting held at the end of each sprint to reflect and improve.
- Planning a release has overhead. For example, sprint planning meeting is often too long and not detailed enough due to insufficient business involvement, insufficient understanding of the business problem, and insufficient requirements decomposition.
- Estimate is always wrong. Estimate problem is really a shared understanding problem on the product side.
- Software developers are being driven without their own priority.
- Non-backlog work is not measured and even frowned.
- Developer passion stifled.
- No new path to explore, they are all laid out.
- Lower retention rate.
- Messier architecture due to less time.
- Manifesto for Agile Software Development
- It's Ordered -- Not Prioritized!
- A Drawback of Agile
- Scrum Will Die
- Intro to Agile Scrum in Under 10 Minutes - What is Scrum?
- Scaled Agile Framework
- Scrum on BDD on DDD - an Agile Development Stack
- Spikes in Scrum: The Exception, not the Rule
- The Real Reason We Estimate
- SCRUM methodology vs. Agile Methodology