To fulfill organization needs , defined complete model to adapt Agile (Scrum) methodologies. This guideline document was prepared to help people understand and adapt the agile best practices.

1. AGILE MEETINGS/ACTIVITY GUIDELINES 1
Agile Meetings/Activities Guidelines
Backlog
Grooming
Story Sizing
High Level
Release
Planning
Iteration
Planning
Daily Stand-Up
Iteration
Review &
Close
Retrospective
On Going Project Planning Iteration
Planning
Sprint Execution
Backlog
Grooming
Story Sizing High Level
Release Planning
Iteration
Planning
Daily Stand-Up Iteration Review
& Close (Demo)
Retrospective
Frequency:
Bi‐Weekly, or as
frequently as
needed/possible
*This can be
informal, but should
be done consistently
in order for teams to
effectively Review
Stories and Plan
Iterations
Frequency:
Bi‐Weekly, at least
once per iteration,
more often if
significant changes in
backlog / new work
requests
*This should be done
at least a week in
advance of the
Iteration Planning
session, to allow time
to understand the
Stories planned;
*This may be
included as part of
Backlog Grooming,
as well as a more
formal, team‐byteam
Frequency:
Monthly or bi‐
Iteration, depending
on Release/Iteration
cycles
*This can be informal,
but should be done
consistently in order
for teams to effectively
Review Stories and
Plan Iterations
Frequency:
Beginning (first day)
of each Iteration
*This is a formal,
team‐by‐team or
cross‐team exercise.
Frequency:
Daily
Frequency:
End (last day) of
each Iteration
Frequency:
End (last day) of each
Iteration, after
Close or before next
Iteration Planning, or
whenever an event
necessitates
*This is a critical,
team‐by‐team
exercise.

2. AGILE MEETINGS/ACTIVITY GUIDELINES 2
or cross‐team
exercise (for larger,
complex projects).
Participants:
PO,PM, SA, TL (other
team members
and SMEs as needed)
*Scrum Guide
suggests that this
activity should
include the entire
Development team
Participants:
Core Team, PM,PO
and TL
Participants:
TL,PM, PO, SA and
Tech Lead
(other team members
as needed)
Participants:
Core Team, PM,TL
and PO
Participants:
Core Team, TL, PO and
PM
(PO & PM optional –
should be available to
answer
questions, but not to
influence team
decisions)
Participants:
Whole Team, PO,PM,
TL and anyone else
who is interested
(business users and
stakeholders) TL
facilitates, but Team
prepares for and
runs the meeting
Participants:
Core Team, TL,PM
and PO
Purpose:
To continually be
looking ahead at the
items for the next 1‐2
iterations, to
consistently refine
and organize the
Backlog and prepare
for Story Sizing and
Release Planning
efforts
‐ Next Iteration:
Focus on key
requirements for
items scheduled for
that Iteration and
specifically
Acceptance Criteria
‐ Two Iterations out:
Focus on planning –
are there
infrastructure
concerns? Do we
understand
dependencies and
resource constraints?
Purpose:
To provide team the
opportunity to
review and discuss
Stories in the
Backlog, Size those
that are ready and
prepare for the up‐
coming Iteration
Planning activity.
Purpose:
To create a well
aligned backlog across
teams, commit to
release goal, and to
loosely assign Stories
to the Iterations
within a Release
Purpose:
To determine and
commit to what will
actually be worked
on in the current
iteration and identify
the tasks required to
complete
Purpose:
Daily planning meeting
for the team;
Team Accountability and
Visibility
Purpose:
For the team to
demonstrate to the
Product Owner (and
other stakeholders)
the items that were
completed during
the iteration, and to
validate Stories that
can be closed, as
well as those that
were not completed
(if any)
Purpose:
For the team to
identify areas where
they can make
improvements to
communications,
process, productivity,
approach, etc...

3. AGILE MEETINGS/ACTIVITY GUIDELINES 3
Agenda:
‐ Review Backlog in
relation to Release
plan
‐ Review and verify
backlog items for
immediate/next
Iteration
‐ Decompose stories
that are very large
for upcoming
Iterations into
smaller stories
‐ Add New Stories, as
necessary
‐ Prioritize/Order
rank Stories
‐ Define Acceptance
Criteria for each
Story
‐ Review Stories in
relation to Overall
Goals, Vision,
Business Value,
Dependencies,
Priority, and ROI
etc...
‐ Identify all
Gaps/Unknowns
requiring SA/PO
follow‐up
‐ Inform team(s) as
Stories are ready for
Sizing and/or Release
Planning
Agenda:
‐ Review All Stories in
Backlog that have
been groomed and
are planned
(candidates) for
upcoming
iteration(s)
‐ Ask questions of PO
and/or SA to remove
ambiguity and
decompose or
consolidate Stories
as needed
‐ Identify any known
dependencies
‐ Assign (vote on) a
Size to Stories, based
on a relative
assessment of:
‐ Level of Effort
‐ Complexity
‐ Unknowns
Agenda:
‐ Review the Release
Goal. (Do not skip this
step)
‐ Align stories on the
wall by team backlogs
(If
multi/cross‐team,
start with individual
backlogs,
then consolidate view)
‐ Clearly mark
Dependencies across
teams/backlog items.
‐ Add New Stories, as
necessary
‐ Based on the team’s
projected velocity and
story priorities, target
the iterations that the
stories should go into
Agenda:
‐ Team Capacity
Planning
‐ Review Iteration
Objectives with PO
‐ Story Review (Walk
through all stories
targeted for the
Iteration; Allow team
to ask questions so
everyone
understands what it
means to be 'done'
with each)
‐ Resize Stories as
needed, being aware
of impact to overall
iteration
‐ Team works
together to ID and
estimate Tasks
needed to complete
each Story
‐ Compare allocated
Capacity with
estimated hours and
adjust
‐ Team Commitment
(can this get done?)
‐ Post meeting – TL
works with Team to
create the Team
Iteration board and
update ALM tool
accordingly
Agenda:
For each participant:
‐ What did I accomplish
yesterday?
‐ What do I plan to
accomplish today?
‐ What are my
roadblocks?
Agenda:
‐ Team briefly
reviews the stories
that they feel were
completed in the
Iteration
‐ Team Demonstrate
the completed
iteration items
‐ PO and Team agree
on items being
“Done” or not, based
on defined
Acceptance Criteria
‐ Team closes the
completed iteration
items (This can be
done post‐meeting)
‐ PO/TL reviews the
high level iteration
plan so the team can
see where they are
relative to the
overall project
Agenda:
Team identifies and
discusses:
‐ What went well?
‐ What did NOT go
well?
‐ Team identifies
Action Items and a
plan for
improvement in the
upcoming iteration(s)
*this is the most
important step
Tips:
‐ Time box meeting
to 1 hour.
‐ Team should
allocate 5‐10% of
Tips:
‐ Time box meeting
to 1 ‐ 2 hours (as
short as possible),
based on the amount
Tips:
‐ Time box meeting to
1 hour.
‐ For larger projects,
based on the team's
Tips:
‐ Time box meeting
to 2 ‐ 4 hours,
depending on
Tips:
‐ Time box meeting to 15
minutes*.
‐ Only information
relevant to team
Tips:
‐ Time box meeting
to 1 ‐ 1 1/2 hour,
depending on scope
of iteration, amount
Tips:
‐ Time box meeting
to 30 minutes.
‐ Spend 15 minutes
identifying items.

4. AGILE MEETINGS/ACTIVITY GUIDELINES 4
capacity to grooming
effort.
‐ Go through backlog
in priority/rank
order.
of work to be
completed, more
time for new
projects.
‐ Time box the
discussion on each
item; keep the team
focused on getting
just enough info for
sizing.
‐ Briefly document
acceptance criteria,
risks, questions,
requirements that
are identified during
the discussion
(remember, the
purpose is to
understand and size
stories, not to gather
Requirements, and
not Tasking).
‐ ID a Story that
represents a
"baseline" and size
other stories relative
to it.
‐ Each team member
should vote on story
size. Repeat until
consensus reached.
projected velocity,
estimate the number
of iterations it will
take to complete the
project and adjust
timeline/budget/scope
as needed.
‐ Include the team if
there are a lot of
dependencies
anticipated and/or the
tech lead doesn’t have
enough knowledge to
define those.
‐ Don’t try to do this in
ALM tool; Use
Story/Task Cards
and/or export the
stories to Excel, if
possible.
‐ Do not do Release
Plan if stories are not
sized, prioritized
and/or are missing
reasonable acceptance
criteria ‐ i.e. Backlog
Grooming has not
taken place.
team size, iteration
length, backlog/story
quality
‐ Determine team
Capacity in hours
before getting into
specific Stories
(Working days only,
exclude TL/PO/PM
time, exclude SA time
not allocated to
current Iteration
items).
‐ At the beginning of
planning, review any
relevant, prior
retrospective items.
‐ Time box agenda to
ensure all Stories and
Tasks can be
identified and
discussed thoroughly.
‐ If possible, do not
assign tasks during
this meeting, just
identify/estimate.
‐ Don’t try to do this
in ALM tool; Use
Story/Task Cards
and/or export the
stories to Excel, if
possible.
progress and planning
should be discussed.
‐ Keep the team focused
on reporting completion
on tasks, not just
reporting on individual
activities.
‐ Team Lead should be
listening for (and
explicitly asking about)
impediments/roadblocks
that are preventing the
Team from succeeding;
‐ TL should only report
status if they own tasks
or roadblocks.
‐ Problems should not
be resolved during the
meeting; identify, then
move on...
‐ Everyone should
update their tasks (team
iteration board and ALM
tool) prior to, or
immediately after, the
meeting.
‐ Burndown chart should
be posted on the team
iteration board.
of new functionality
to demo and size of
audience.
‐ Each Team member
should present
based on their
contributions to the
Iteration.
‐ If there is a large
stakeholder
audience, you
may want to split the
agenda to start with
a Team‐PO/PM
demo/review,
followed by a
Stakeholder demo,
or vice‐versa.
‐ Have each person
write up their
thoughts and then
share and discuss all
to categorize and ID
patterns or themes.
‐ Pick the most
important one or two
and spend 15
minutes brain
storming possible
solutions.
‐ Team Leads, take
care to facilitate, but
not force, the
conversation and not
lead the team to
conclusions; allow
the team to self‐
direct and determine
what is important to
them.
‐ When retrospective
get boring and/or
people just talk
about what went
well, try to innovate.
Try any sort of new
technique or fun
activity to generate
fresh insight.
Notes: PO = Product Owner, PM= Project Manager/Coordinator TL = Team Lead, SA = System Analyst, SME = Subject Matter expert,
Core Team = Team members actually doing the work each iteration to deliver the working system.