Processes and procedures for managing agile projects in the Federal Acquisition domain

1. 1
NES JIRA PROJECT
MANAGEMENT
PROCEDURES
V4 5/17/18

2. 2
NES PROCEDURES
Table of Contents
1. PROCESS, DATA, and Roles Flow for NES Development and Deployment ............................ 3
2. Audience for this Procedure................................................................................................ 5
3. Change Management.......................................................................................................... 6
Change Management ‒ Process for Changing Acceptance Criteria in JIRA: ..................... 6
Change Management ‒ Process for Capacity Changes in Jira.......................................... 6
4. Estimating User Stories and Their Subtasks......................................................................... 7
Estimating Meeting Preparation .................................................................................... 7
Steps for Estimating....................................................................................................... 7
5. Issue Definitions and How to Create Each Level in JIRA ....................................................... 9
6. Writing User Stories and Acceptance Criteria.................................................................... 11
Syntax of the User Story .............................................................................................. 11
User Story Template.................................................................................................... 11
Story Check List ........................................................................................................... 11
User Stories and SubTasks ........................................................................................... 11
Writing the Acceptance Criteria................................................................................... 11
7. Scrum Board ..................................................................................................................... 12
8. Test Case Management..................................................................................................... 13
JIRA Issue (Story) Workflow......................................................................................... 13
9. Slack ................................................................................................................................. 14
10. Trello .............................................................................................................................. 15
11. Scrum Ceremony/Meeting Schedule ............................................................................... 16

3. 3
1. PROCESS, DATA, AND ROLES FLOW FOR NES DEVELOPMENT AND DEPLOYMENT
Figure 1 ‒ Process flow for NES project from Initial User Story through User Acceptance Test
Step Step Action Transitions
❶ User Stories, Tasks, and Bugs in active Sprint are pulled into this status by the assigned Developer
❷ User Stories, Tasks, and Bugs in an active Sprint are pulled into this status by the assigned Developer
❸ Tests are pulled into this status by the Test creator
❹ Tests move between these statuses by the SIT Tester
❺ Tests move between these statuses by the SIT Tester
❻ Tests are pulled into this status by the SIT Tester once the linked Bug is marked as “Done”
❼ Tests move between these statuses by the SIT Tester
❽ Tests are pulled into this status by the UAT Tester
❾ Tests move between these statuses by the UAT Tester
❿ Tests move between these statuses by the UAT Tester
⓫ Tests move between these statuses by the UAT Tester
⓬ Tests are pulled into this status by the SIT Tester
⓭ On Hold- All issue types can be placed on hold from a status of open

4. 4
Each element of the process flow in Figure 1 has the following, shown in the table below Status,
Location, Related Issue(s) (in Jira nomenclature), and Owner.
Status Location Related Issues Owner
Open
NES Product
Backlog, NES
Sprint Backlog,
or NES Active
Sprint Board
Capability, Epic, User
Story, Task, Bug, and Sub
Task
Product Owner
On Hold
No Board
Location
Suspended
No Board
Location
In Development
Active Sprint
Board User Story, Task, Bug,
and Sub Task
Development Team
Done
Active Sprint
Board
SIT Open
SIT Board
Backlog
User Story and Bug Product Owner
SIT in Progress
SIT Board
Backlog or SIT
Kanban Board
Test
SIT Test Team
SIT Failed Sit Kanban Board
SIT Passed
SIT Kanban
Board
UAT Open UAT Open Board
UAT Test Team
UAT In Progress
UAT Board
Backlog or UAT
Kanban Board
UAT Failed
UAT Kanban
Board
UAT Passed
UAT Kanban
Board

5. 5
2. AUDIENCE FOR THIS PROCEDURE
Audience Members Email
BA Lead
Business Analysts
C4 Leadership
Developers
hCentive
Product Owners
Scrum Master
Team
Technical Lead
Testing Lead
Testers

6. 6
3. CHANGE MANAGEMENT
Change Management ‒ Process for Changing Acceptance Criteria in JIRA:
Change Management Scenarios:
n If the User Story is in the Product Backlog or an inactive Sprint Backlog ‒ Just update the
acceptance criteria. Should be discussed in User Story grooming session.
n If the User Story is “Open” ‒ Update the acceptance criteria (strikethrough, do not
delete) and re-estimate t-shirt size. Add a comment of who made the change and how
much the estimated time is changing by. Should be discussed on “current-Sprint-chat”
Slack channel.
n If the Story cannot be completed in the Sprint ‒ Split the Story and put what you can’t do
in the Product Backlog.
n If the User Story is “In Development” ‒ Update the acceptance criteria (strikethrough,
do not delete) and re-estimate t-shirt size. Add a comment of who made the change and
how much the estimated time is changing by. Should be discussed on “current-Sprint-
chat” Slack channel.
n If the Story cannot be completed in Sprint- Split the Story and put what you can’t do in
the Product Backlog.
n If the User Story completely changes due to the acceptance criteria ‒ Change status to
“Suspended” and link any new resulting stories to the original one by selecting "is caused
by" under the linked issues section when creating the new User Story. Add a comment to
document the changes on both the new and old User Story. Should be discussed on
“current-Sprint-chat” Slack channel.
n If you are unsure how the acceptance criteria will change but know that it will ‒ Change
status to “On Hold” and add a comment to document the changes. This goes for no
matter where the User Story is. Should be discussed on “current-Sprint-chat” Slack
channel if the Story is in an active Sprint or the User Story grooming meeting if the Story
is in a Backlog.
n If the User Story is “Done” and there is a gap in the acceptance criteria when doing
integration testing ‒ Create a new User Story that accommodates the gap and add to the
Product Backlog. To be discussed during next Sprint grooming session.
Change Management ‒ Process for Capacity and Functionality Changes in Jira
There are 5 scenarios for change control on NES that impact the capacity planning and
functionality of the Capabilities, Epics, and Stories in Jira. Changes are controlled to maintain
the integrity of the NES project’s functionality, testing process, security validation, performance
assessments, and other attributes of the systems.
1. A Story in the Product Backlog is not OPEN, but its contents are changed
2. An OPEN Story is incomplete in the current Sprint and returned to the Product Backlog
3. An Epic planned for the current Release is moved to another Release
4. A Planned Epic is removed for a Release
5. Story and Epic completion criteria are added, changed, or deleted

7. 7
4. ESTIMATING USER STORIES AND THEIR SUBTASKS
Estimating Meeting Preparation
n Participants
- Product Owner
- Scrum Master
- All Team Members
n Meeting Agenda
- Define the Goal of the Meeting
- The Product Owner presents the portion of the Product Backlog that needs to be
estimated
- For each item selected
v Explain the Story to the participants
v Gain consensus on the Tee‒Shirt size for the Story
v Gain consensus on the Hours for the Subtask size, derived from range of hours in the
Tee‒Shirt size.
Steps for Estimating
6. To be completed by Product Owners prior to the Sprint Grooming Meeting.
n Write the User Story in the defined format
n Size the User Story using T‒Shirt sizes
n Estimate whether you think a User Story is extra-small, small, medium, large, or extra-
large, compared to the Stories that have been developed in the past
n This estimate is used to define the relative size of the stories compared to the other
stories in this Sprint and past Sprints
n By removing the implied precision of a numerical score, we are free to think more
abstractly way about the effort involved in a User Story
n There are some issues with the approach we must be aware of
- Non-numerical scales are generally less granular. While that can speed up the voting
process by reducing the number of options, it may also reduce the accuracy of velocity
estimates
- The ability to compare stories with each other can be more complicated, since there is
no clear mathematical relationship between a medium and an extra-small
v T-shirt size scales require extra effort on the part of the person coordinating the
agile process
v The T-shirt sizes next need to be converted to numerical values for tracking effort
over time and charting an estimated performance for the team
v The T-Shirt size will be added in the “T-Shirt Size” field of the User Story. T-shirt
sizing is only done at the User Story level.

8. 8
7. After the “T-Shirt Size” has been added to the User Story and the User Story has been
groomed, to assure the Acceptance Criteria and clear and concise, the Developers estimate
the Hours for each SubTask, using the range available from the Tee‒Shirt size during the
Technical Review Meeting.
n T‒Shirt sizes refer to a range of hours in the following manner
- XS ‒ 1 to 4 hours
- S ‒ 5 to 12 hours
- M ‒ 13 to 24 hours
- L ‒ 25 to 48 hours
- XL ‒ 49 to 64 hours
v The number of hours per day is currently set at 6.
v For XL stories, they will be sliced into smaller Stories.
v The Development team will confirm the Product Owner’s estimate is still credible
and refine that estimate into an hour estimate with the concurrence of the Product
Owner.
8. The Hours for each Sub Task will be placed in the “Time Estimate” field of the Sub Task once
the Sprint has started. Please note that ALL Sub Tasks must have time estimates entered
and agreed upon by close of business on the first Monday of the new Sprint. Time estimates
are only done at the Sub Task level.
n After T-Shirt sizes are defined by the Product Owner and the Development Team comes
to a consensus that those sizes are credible, the hours for the Sub Tasks are developed.
This process can follow several paths, but Fist of Five, or some other concurrence1
development process is used to have the Development Team and the Product Owner
n Logging time ‒ To be done by the Developer assigned to the Sub Task.
n Once work begins on a Sub Task in the active Sprint, it is move it to the “In Development”
column. Time logged on each Sub Task should be updated by close of business every day.
n Time for the work performed is only logged at the Sub Task level.
n Logging time for a Sub Task in JIRA:
1. Go to your project’s “Active Sprints” board
2. Click on the Sub Task you wish to log time for
3. Select the plus sign next to “time tracking” in the righthand corner of the issue.
4. Enter your time spent
5. Select appropriate “Time remaining” option-
“Automatically update” ‒ If all time spent working was part of the original time estimate.
v “Update to a specific time”- If time remaining changes. Manually input the
remaining time in the adjacent field.
v “Don’t update time remaining” ‒ If time spent was not accounted for in original time
estimate.
v Confirm the “Date started” is accurate and adjust if needed.
v Select the blue “Log time” button.
1 Concurrence is agreement by the group, no one dissenting. Consensus seeks wide spread agreement among all the group. But there
can be those who disagree. For the Scrum Team to Commit there must be coinsurance, not just consensus

9. 9
5. ISSUE DEFINITIONS AND HOW TO CREATE EACH LEVEL IN JIRA
n Capability: Highest level in hierarchy. The Capability is measurable, but its real purpose is
to enable the business to accomplish something. It describes what the business does not
how it does it.
- Created by C4
- Typically spans one or more releases and makes up the product road map
- Contains multiple Epics
n Epic: Second level in hierarchy. The Epic contains the functionality needed to implement
the Capability. Each Epic includes a statement of benefits and defined acceptance
criteria.
Epics are structured as <Action><Result><Object>.
- Created by C4
- Typically, 2‒4 weeks in duration and completed within a release
- Contains multiple User Stories
n User Story: Third level in hierarchy. Short descriptions of a small piece of
functionality, written in the user’s language. The user can be a person or a system. User
stories are written in future perfect tense “as a (role) I want (something) so that
(benefit)”.
- Report to the Product Owner and created by C4
- To be completed in a single Sprint
- Every User Story has acceptance criteria which answers the question “how do I know it
will work?”
- Contains 1 or more Sub Tasks
n Sub Task: Lowest level in hierarchy. A single unit of work contained within the User Story.
- Created by the development team after the associated User Story has been groomed
- Assigned to the Developer and Vendor specific
n Task: Equal to the Story level but not part of the hierarchy. A Task is a piece of work that
needs to be completed by a Developer and affects their capacity.
- Assigned to upcoming Sprints during Grooming Sessions
n Bug: Equal to the Story level but not part of the hierarchy. A Bug is a Story that fails
either systems integration or user acceptance testing and is put back in the NES Product
Backlog by the Product Owner.
- Follows the same structure as a User Story
- Assigned to upcoming Sprints during Grooming Sessions
n Test: A single unit of work derived from a User Stories’ acceptance criteria. Created and
owned by a Tester during System Integration and User Acceptance testing. A Test must
be measured as either pass or fail.
- A User Story can have one or multiple Tests linked to it
v Not assigned to Sprints. Progress is tracked on Kanban boards

10. 10
6. HOW TO CREATE AN ISSUE IN JIRA
n Capability
1. Once in your project, select the “plus” sign in the upper left‒hand corner
2. Select your issue type
3. Complete the “Summary” field
4. Select “Create”
n Epic
1. Once in your project, select the “plus” sign in the upper left‒hand corner
2. Select your issue type
3. Complete the “Summary” field
4. Select “Create”
n User Story
1. Once in your project, select the “plus” sign in the upper left-hand corner
2. Select your issue type
3. Complete the “Summary” field with the “as a (role) I want (something) so that (benefit)”
sentence. Please note this is all you will put here
4. Select the Product Owner for the Story in the “Reporter” field
5. Add your acceptance criteria to the “description” field in a numbered list. For language that
still needs to be flushed out, add “PLACEHOLDER TEXT” in parenthesis
6. Attach any rules or supporting documents
7. Select the Epic associated with the Story in the “Epic Link” field
8. Add the User Story size to the “T‒Shirt Size” field (XS for extra small (4 hours), S for small (12
hours), M for medium (24 hours), L for large (48 hours), or XL for extra‒large (64 hours))
9. Select “Create”
n Sub Task
1. Once in your project, open the User Story you would like to enter a Sub Task for in a new tab
2. Select the ellipsis in the upper righthand corner
3. Select “create Sub Task”
4. Complete the “Summary” field
5. Assign the Sub Task in the “Assignee” field
6. Add the time the task will take to complete in the comments section
7. Select “Create”
n Task
1. Once in your project, select the “plus” sign in the upper left-hand corner
2. Select your issue type
3. Complete the “Summary” field
4. Select “Create”
n Bug
1. Open the Test in a new tab and select the “edit” option
2. Re open by changing the status to “Open”
3. In the “type” field, change the issue to “Bug”
4. You can now find your Bug in the NES Product Backlog
n Test
1. Once in your project, select the “plus” sign in the upper left‒hand corner
2. Select your issue type
3. In the “Summary” field add the User Story and test case number (IE- 583 TC 1)
4. Add the acceptance criteria in the “Description” field
5. Select the User Story linked to the Test by selecting “relates to” in the “Linked Issues” field and
adding the User Story in the following “Issue” field
6. Select “Create”
7. Open the Test in a new tab and change the status to either “SIT Open” or “UAT Open”
8. Add “Test Steps”, “Test Data”, and “Expected “Results” under “Test Details”

11. 11
7. WRITING USER STORIES AND ACCEPTANCE CRITERIA
User Stories are a tool in agile software development to capture the description of a software
feature form an end‒user perspective. The User Story describes the type of User, what they
want and way they want it. A User Story helps create a simplified description of the desired
outcome of the Feature.
Syntax of the User Story
As a <type of user>, I want <some feature> so that <reason>
User Story Template
WHO
Are we building the software for? Who is
the User
As a <Type of User>
WHAT
Are we building? What is the intention of
this software for the User?
I want <some goal or objective>
WHY
Are we building this software? What is
the value for the customer?
So that <benefit or value>
Story Check List
n Keep them short and simple
n Write the from perspective of the User
n Make the Value or Benefit of the Story clear ‒ what is the reason for the Story?
n Describe one piece of functionality of the Story. Spilt if more than one piece
n Write the Stories as a team
n Define the Acceptance criteria to show the MVP
User Stories and SubTasks
User Stories SubTasks
A User Story is the WHAT A Task is the HOW
User Stories describe a piece of Functionality from
the point of view of the User
“What are the activities needed to perform in order
to deliver the outcomes of the User Stories
User Stories divide business processes into Feature Tasks are individua pieces of Work
Writing the Acceptance Criteria
n To clarify what the Team should build before they start work?
n To ensure everyone has a common understanding of the problem
n To help the Team Members know when the User Story is complete
n To help verify the Story thorough automated testing
n Acceptance should include:
- Negative scenarios of the functionality
- Functional and non‒functional use cases and any Performance guidelines
- What system or feature the User Story intends to do
- End‒to‒user flow and the impact of a User Story to other Stories and their feature
- Any User Experience (UX) concerns

12. 12
7. SCRUM BOARD
The Scrum Board Applies to all User Stories and their Sub Tasks, and Tasks in the active Sprint
which are owned and updated by Developers. Status and time for should be up to date for the
daily scrum call.
n Open
- User Story‒ Has been assigned to a PO and T‒Shirt size is agreed upon. All related Sub
Tasks created in the Tech Review are open as well.
- Sub Task‒ Has been assigned to a Developer and the time estimate has been added/
agreed upon. No work has been started.
- Task‒ Has been assigned to a Developer but no work has been started.
n In Development
- User Story‒ At least one Sub Task for the Story has been moved to “In Development”.
- Sub Task‒ Work has been started. All unit testing and development is done during this
status. Time should be updated daily.
- Task‒ Work has been started.
n Done
- User Story‒ Development and unit testing for every related Sub Task has been
completed. The Story is ready for integration testing.
- Sub Task‒ All development and unit testing for that Sub Task has been completed.
- Task‒ All work has been completed.

13. 13
8. TEST CASE MANAGEMENT
User Stories pass through three stages of testing ‒ Unit Testing (UT) in Development, System
Integration Testing (SIT), and User Acceptance Testing (UAT), on their own JIRA boards. UT is
done by Developers “In Development” and moved to “Done.” The story moved to SIT Open by
CGI on the SIT Board. In SIT, if passed, Story moves to UAT Open by C4 testers on UAT board.
JIRA Issue (Story) Workflow
1. Once a sprint is complete, “Done” User Stories move to SIT by having their status changed to
“SIT Open.” The individual closing the sprint will also be the one to change the Stories’
status. All User Stories with the status of “SIT Open” can be found in the SIT board backlog.
2. Prior to changing a User Stories’ status to “SIT In Progress”, it must be assigned to a Tester
and turned into a Test issue type.
A. If the Test fails, Tester will change the status to “SIT Failed”. The Product Owner who the
Test reports to will then be responsible for either reopening the Test and changing the
issues’ type to “Bug”, changing requirements, or accepting the failure.
B. If the Test passes, the Tester will change the status to “SIT Passed”.
3. The Product Owner overseeing the Testers, is responsible for moving the Test Story to UAT
by changing status to “UAT Open”. “UAT Open” Tests can be found in the UAT board backlog.
4. Prior to a Test’s status being changed to “UAT In Progress”, it must be assigned to a Tester.
A. If the Test fails, the Tester will change the status to “UAT Failed”. The Product Owner who
the Test reports to will then be responsible for either reopening the Test and changing the
issues’ type to “Bug”, changing the requirements, or accepting the failure.
B. If the Test passes, the Tester will change the status to “UAT Passed”.

14. 14
9. SLACK
n Slack Channels
- Used for asking questions, sharing documents, and overall collaboration between C4,
CGI, and hCentive.
- When addressing individuals directly in a Slack channel, type “@” followed by their
name. For replying to a message directly, start a thread by hovering over the message
and selecting the “Start thread” icon (or “Reply to thread” if the thread has already
begun).
- Channel usage‒
v # current‒Sprint‒chat‒ For all topics related to the current Sprint.
v # general ‒ Can we delete one of these?
v # random
v # scruminfo‒ For all Scrum and process related topics.
n Slack Direct Messaging
- Used for reaching out to individuals directly when the topic does not relate to or could
be useful to anyone else.
n Slack Notifications
- Make sure your notification preferences are set by selecting your name in the upper
left-hand corner ➜ choose “Preferences.”
n Set a Status in Slack
- Status is used to let others know if you are in a meeting, on PTO, working from home,
etc.
- To set a status, select your name in the upper left‒hand corner ➜ choose “Set a
status.”

15. 15
10. TRELLO
n Team Members ‒ All NES Teams
n Design ‒ the first column is the Backlog where tasks with unknown or not current due
dates go. Each of the following columns represent a Plan of the Week, where members
add their weekly tasks. This board increases visibility on the Team’s capacity to allow
greater collaboration
n Add a Card ‒ used for action items or nonrecurring meetings. Applies to all projects and
thought of as at the Story Level. Cards can be added to any week or backlog at any time.
- Select “Add a Card,” type a one sentence summary of what will be done that week.
- Assign the card to all relevant parties by clicking on the ellipsis in the lower right-hand
corner of the card and select “members.” Please not that all cards must be assigned to
at least one team member.
- If the card is related to the NES project, add the pink “NES Project” label by clicking on
the ellipsis in the lower righthand corner of the card and select “labels.”
- Select the green “Add” button
- If the card has a due date other than at the end of the week, then add a due data by
selecting the pencil icon in the upper righthand corner of the card. Choose “Change
Due Date” enter the date and time the card is “due”. Select the green “Save” button.
This can also be dome by clicking once on the care to open the detail screen.
n Edit a Card
- Archive ‒ to be used if a card is a duplicate or no longer relevant. Card’s cannot be
deleted in Trello, they can only be archived.
v To archive a card, select the pencil icon in the upper right-hand corner of the Card
and choose “Archive.” This can be done by clicking once on the card to open the
detail screen.
v To review archive Cards, select the “Show Menu” option in the upper righthand
corner of the Board ➜ Choose “More” ➜ Choose “Archived Items.” This is also
where you can go to send items back to the board that were archived.
- Checklist ‒ if a Card has multiple tasks, create a checklist to track those tasks to
completion.
v To create a Checklist, click on the Card once to open the Detail Screen ➜ select
“Checklist” from the righthand “add” column ➜ choose an existing checklist of
desired ➜ select the Green “add” button ➜ add checklist items in the “add an item”
field and selecting the “add” button.
- Comment ‒ add a comment by clicking once on the Card to view the detail screen
- Move ‒ Cards can be moved to different weeks by clicking and dragging. When the
Card is moved, add the reason for the move in the Comments field
- Watch ‒ turning on this feature will notify you of all activities related to the Card.
v To watch a Card, click on the Card to open the Detail screen ➜ select “Watch” under
the right-hand “actions” column.
n End of Week activity ‒ all cards assigned to you should be updated with their current
status.
- Select the pencil icon ➜ Choose “labels” ➜ select Blue for “done,” Yellow for “Not
Done.
- Move any cards “Not Done” to the next week’s list and add a comment explain why.

16. 16
11. SCRUM CEREMONY/MEETING SCHEDULE
Ceremony Participants Goal and Activities Entry Criteria Actionable Outcomes
❶
Daily Scrum
Stand up
Meeting
§ Scrum Master
§ Tech Lead
§ Product Owners
§ Business
Analyst
§ Testing Lead
§ Development and Test teams speak to the
following regarding specific stories in Jira by
prioritized Story.
- What did I do yesterday that helped the
Team meet its goal?
- What will I do today to help the Team meet
the Sprint Goal?
- Do I see any impediments that prevent me
or the Team from meeting the Sprint goal?
§ Any new Stories, go to the Story Time
meeting
§ All active Stories and Subtasks
statused with hours logged and
Revised Estimates updated.
§ Speak about the estimate to
complete and the confidence of that
estimate.
§ State how the Sprint is progressing
by stating Physical Percent progress.
Evidence for this progress will be the
"Remaining Estimate," after updating
the "Logged Time"
§ Identify impediments or further
discussions on stories or bugs with
team (discussions performed offline)
§ State any changes in the Stories and
Tasks as the result of "yesterday's"
work that impact the Sprint Backlog
❷
❸
Product
Backlog
Grooming
(Pre‒Planning)
§ Scrum Master
§ Tech Lead
§ Product Owners
§ Business
Analyst
§ Testing Lead
§ Review User Stories in preparation for Story
Time
§ Collect New Stories from existing Epics and
Capabilities
§ Collect New Epics
§ Collect New Capabilities
§ Prioritized order of the product
backlog reflecting the greatest need
of the Management and Product
Owners
§ Candidates for grooming include
Stories identified as not ready to
complete with the next Sprint or
need multiple days of research
§ Review of Capabilities or Epics on the
Product Roadmap
§ A Groomed Product Backlog, ready
for Story Time, showing the priority
of each User Story and the candidate
Sprint, if not already assigned to a
Sprint
§ No commitments are made during
Backlog Grooming
Story Time
(Sprint
Planning)
§ Product Owners
§ Scrum team
§ Test Team
§ Product Owner and Team negotiate which
stories will be in the next Sprint
§ This is a working session not a management
decision session
§ Scrum Master makes sure everyone is ready
for Story Time
§ Review groomed/prioritized backlog items
and commit to work to for upcoming Sprint
§ Product Owner is prepared to
identify the highest priority Stories
that generate highest business value
§ Development Team prepared to
provide assessment of the impact of
those choices on their work cycle.
§ Test Team
§ Well‒formed Stories ready
development
§ Estimated Stories in quantified units
of measure (Hours).
§ This not Backlog Refinement
§ Scrum master assures Story Time is
short, produces good quality stories
and the right people are in
attendance.
§ Confirmation the Stories can be
delivered in the Sprint
❹
Technical
Review
§ Developers
§ Scrum Master
§ Testers
§ Business
Analyst Lead
§ From the Scrum Guide ‒ The development
Team starts by designing the system and the
work needed to convert the Product Backlog
into a working Product Increment
§ Assigned stories have sub‒tasks authored by
developers completed prior to Planning
Session in ❷ and ❸
§ An understanding of the Story at the
high level
§ An understanding of the design and
architecture constraints for the Story
(if any)
§ Design and technical sub‒tasks
developed
§ Confirmation of acceptance tests
cover the needed functionality
§ Make sure the YAGNI principle is
applied to prevent over‒engineering
the solution
Testing Triage
§ Test
§ BA Lead
§ Tech Lead
§ Review bugs and defects by Test Lead
§ Prioritize items based on severity in the
backlog or as addition to the current Sprint to
be worked
§ Analyzed Defects for root cause
§ Defects placed in Product Backlog for
grooming
§ Produce candidates to be worked in
the next Sprint or added to the
current Sprint.
❺
Code Review
and Demo Dry
Run
§ Developers,
Scrum Master,
Testers,
Business
Analyst Lead
§ Review code for stories that have been
completed with the group and do a dry run of
what will be demonstrated in Sprint
Review/Demo
§ Complete Stories marked as
complete in Jira
§ Test outcomes as evidence of
completion, with test results logged
in some
§ Collaboration and team building with
dev team to review and discuss
completed code and share best
practices. Do a dry run or discussion
of what is to be demonstrated
❻
Sprint Review
Demonstration
§ Team
§ C4 Leadership
§ Demonstrate and close out stories that have
been completed in the Sprint
§ Product Backlog updated
§ Demonstration participants have a
script of what will be shown to
connects working software with
Stories
§ Demo completed work for the Sprint
to team and leadership
§ Product Backlog Updated after
review
§ Done products showcased on
workstations for stakeholder
❼
Sprint
Retrospective
§ Scrum Team
§ C4 Leadership
§ What went well?
§ What didn’t go well?
§ What have we learned?
§ What is unclear about our process and tools?
§ All Scrum Team members come
prepared with answers to these
three questions.
§ Scrum Master ready to guide the
Team in collecting this information.
§ A collected list of the answers from
the question
§ Solutions to open questions are not
provided in the meeting, but placed
in backlog of Process Improvement
initiatives
❽
Sprint
Commitment
§ Team
§ Product Owner
§ Review candidate Stories for upcoming
Sprint(s)
§ Estimates confirm in units of Tee‒Shirt and
Hours as credible
§ Confirmed Capacity of Development Team for
defined work
§ Commit as a Team to produce the outcomes
from the Stories and Tasks for the Sprint Goal
§ Commit the Story Commitment process, until
anyone one on the Team states we cannot
commit
§ Estimated Stories with Tee‒Shirt
and Hours estimates
§ Defined and understood
acceptance criteria for the
Definition of Done for the Story
§ Ask and answer Can You Commit?
§ The Team produces a set of
committed Stories ready for the
next Sprint.
§ Place those committed Stories in
the Open queue for the next Sprint.

17. 17
Sprint
Week 1
Sprint
Week 2
Monday Tuesday Wednesda
y
Thursday Friday Monday Tuesday Wednesda
y
Thursday Friday
❶ ‒
9:30AM 15
Min.
❶ ‒
9:30AM
15 Min.
❶ ‒
9:30AM
15 Min.
❶ ‒
9:30AM
15 Min.
❶ ‒
9:30AM
15 Min.
❶ ‒
9:30AM
15 Min.
❶ ‒
9:30AM
15 Min.
❶ ‒
9:30AM
15 Min.
❶ ‒
9:30AM
15 Min.
❶ ‒
9:30AM
15 Min.
❹ ‒
10:30AM
30 Min.
❹ ‒
10:30AM
30 Min.
❻ ‒
10AM
1 Hr.
❼ ‒
11AM
1 Hr.
❷ ‒
1PM
2 Hrs.
❷ ‒
1PM
2 Hrs.
❸ ‒ 2PM
1 Hr.
❺ ‒ 3PM
1 Hr.
❺ ‒ 3PM
1 Hr.
❽ ‒ 1PM
1 Hr.
❶ ‒ Daily Scrum Standup
❷ ‒ Product Backlog Grooming (Pre‒Planning) and Sprint Backlog Grooming (Story Time)
❸ ‒ Technical Review of Groomed Stories
❹ ‒ Testing Triage
❺ ‒ Code Review and Demonstration Dry Run
❻ ‒ Sprint Review and Demonstration
❼ ‒ Sprint Retrospective
❽ ‒ Sprint Backlog Commitment to Start Next Sprint