1. Groom the
Backlog
Break Epics
into Stories
Write Epics
Review Epics
and Stories
with Dev team
Prioritize the
Backlog
Estimate the
effort for each
Story
Feedback from the development team will help make better
stories. The acceptance criteria may be completely different after
talking to your developers. If a research spike is required before
other stories can be written then that will be the highest priority
story for this Epic.
Stories should be estimable. If they’re too big they should be
broken down into smaller stories. Plan to be able to complete a
story within one Sprint.
Business needs are prioritized by the Product Manager. Tech
needs are prioritized by the Tech Team. Both will impact the
Sprint Commitment so prioritize both kinds of stories.
Estimate effort using 0,1,2,3,5,8 or 13. This estimate will include
the effort it takes for implementation, including development, QA
and an allowance for unknown factors.
Start to write
development
and QA tasks
Add tasks to each story for the actual work required to complete
the story. When all of the tasks are completed then the story
should be complete also. You can add rough time estimates for
tasks if it helps you.
Epics are a way to capture a need. Epics have stories. Stories
have tasks. Not all stories need to be part of an Epic.
Sprint Planning
Sprint Planning
Meeting
Review the
Sprint Backlog
The development team will agree to commit to complete specific
stories during the current Sprint cycle. Past experience will help
a team determine how many points to commit to based on how
many resources are available. The output of the Sprint Planning
Meeting is a Sprint Commitment.
The highest priority items will be at the top of the Sprint Backlog.
Each of these stories should have estimates before the Sprint
Planning Meeting.
Sprint
Commitment
Review the Sprint Commitment with the product managers. The
PM may change priority based on “must haves” from their
stakeholders compared with what the team has committed to.
Iterate as necessary until the team agrees to deliverables for the
Sprint.
Report
Create a report to track the Sprint Commitment. Report on which
stories and how many story points the team committed to.
Development/
QA Sprint
Track Progress
of each Story
Document
Tasks for each
Story
A Story can be Open, Developed, or Closed. Additional states
might include: In Progress, Dev Complete, QA Complete, PM
Accepted, Verified on QA environment, Closed.
Stories have tasks. These tasks capture the work that is required
to complete the story. Update the status of tasks to monitor
progress. States might include: In Progress or Complete.
Address
Changes in
Scope
Modify Acceptance Criteria for a story.
Write additional User Stories. Either Accept them or move them
to the Backlog.
Drop Stories if they are deemed to be lower priority.
Keep Duplicate or Rejected stories in the Sprint when it’s
determined they are so.
Daily Standups
A Daily Standup will allow the development team and product
managers to discuss what they did yesterday, what they’re
working on today, and if they have anything blocking their
progress on the Sprint Commitment.
Regular
Contact
The development team may want to be in regular communication
with the product managers. Clarifying questions about stories
and acceptance criteria is an expected part of the process.
Address
Blockers
Possible blockers might be:
- Need clarification from a stakeholder
- Need approval for scope changes
- Need PM acceptance
- The development team needs an environment to work
- The development team needs data to work
- The development team needs a code base (repositories,
versioning, commit approvals)
Demo
Address
known issues
Demo stories
to the team
Some stories will be accepted as complete with a new story
added to the Backlog for any remaining scope. Some stories will
need to be moved out of the Sprint entirely and reprioritized.
The Development team demos completed stories to the Product
Managers and any other interested stakeholders. This is a demo,
not a training session.
Get approval
Get approval for the stories completed in the Sprint. This usually
comes from the Product Manager.
Note: PM Acceptance happens outside of the demo.
Sprint
Retrospective
Action Items
Meet as a
team
There should be action items that come from the retro. The team
will become more aligned and efficient if they identify issues and
take steps to address them.
The development team and Product Managers meet to discuss
the Sprint after it has ended. The team discusses what went well,
what didn’t go well, and what they want to do better next time.