GFT Agile Runbook

A guick guide for you to start running your project using an Agile approach.

Contact Person:
Agile Excellence Center

Version: 1.0
 Table of contents
1 Agile GFT Quest 3
2 Tools 4
3 Creating your backlog 5
3.1 Identifying Product Scope 6
3.2 Providing a high-level estimation 7
4 Backlog Grooming 8
4.1 Breaking down the Epic 9
5 Sprint Planning 14
6 Running the Sprint 16
7 Planning the next Sprint 21
8 Tracking Sprint Progress 22
8.1 Daily Meeting 22
8.2 Information Radiators 23
9 Closing the Sprint 26
10 Sprint Review 27
11 Sprint Retrospective 28
12 Tracking Project Progress 29
13 FAQ 31
13.1 Does Agile really work? 31
13.2 How GFT builds a committed team? 31
13.3 What is gamification? 31
13.4 I need Agile help! Who should I contact? 32

GFT Agile Runbook | © GFT Technologies SE 2018 Page 2 von 32

 1 Agile GFT Quest

GFT Agile Runbook | © GFT Technologies SE 2018 Page 3 von 32

 2 Tools

Atlassian JIRA is the tracking tool used by GFT to plan, track and manage Agile and Software
development projects.

Atlassian Confluence is a team collaboration software tool used by GFT to create, share and
collaborate on projects all in one place to keep the projects moving forward, faster.

GFT Agile Runbook | © GFT Technologies SE 2018 Page 4 von 32

 3 Creating your backlog

A backlog is a list of features or technical tasks which the team maintains and which, at a given
moment, are known to be necessary and sufficient to complete a project or a release.

GFT Agile Runbook | © GFT Technologies SE 2018 Page 5 von 32

 3.1 Identifying Product Scope

The first step is to work with the specialists to identify the scope of the product, creating the tasks
to feed project’s backlog.

Creating the EPIC

First, we create the requirement with Issue Type = EPIC.

It represents a group of associated minor stories. It can contain descriptions and attachments
related to this topic.

E.g.: Include field “Registration” in Form

GFT Agile Runbook | © GFT Technologies SE 2018 Page 6 von 32

 3.2 Providing a high-level estimation

In case of the requirement is not completed in terms of information but you have an idea of the
feature to be developed, you can perform the analysis with the specialist team in order to add the
durations of each activities in high level. You can use Real Date or Story Points.

Checking the high-level estimation in Structure View

GFT Agile Runbook | © GFT Technologies SE 2018 Page 7 von 32

 4 Backlog Grooming

In this phase, the PO act adding all necessary information in the epics until it achieve the status
“Ready for Development”. In Jira, you can create labels to show the status. E.g.:
 In_Grooming : Contains partial information into the epic
 Ready_For_Development: All the necessary information was already provided and the
team can plan the development.
 Released: The epic was released to business.

Definition of Ready

DoR is the steps/rules that need to be satisfied in order to have the Epic/Stories ready for
development.
Example:
1. Story must be written as a user story (i.e. “As a <kind of user> I want <feature> so that
<benefit>”).
2. Acceptance criteria must exist and be understood by team.
3. Story has been estimated by the team.
4. UX sketches exist, where appropriate, and are understood by team.
5. Performance criteria exist, where appropriate, and are understood by team.
6. The team understands how to demo the feature.

GFT Agile Runbook | © GFT Technologies SE 2018 Page 8 von 32

 4.1 Breaking down the Epic

At the “Ready for Development” state, it is time to create the Stories and Sub-tasks for the Epic
and assign the same to a Release (Fix Version on Jira).

Creating the STORIES

We can create one or more stories for each Epic, depending on the size of the requirement. E.g.:
As a user I want to inform “Registration” field in order to provide a better identification.

All of them must have the Epic Link informed with the Jira created previously.

GFT Agile Runbook | © GFT Technologies SE 2018 Page 9 von 32

 Creating the SUB-TASKS

For each story, we usually create:

a. 1 or more sub-tasks for the Back-End squad. E.g.: Create Registration column on Client
Table of DB.
b. 1 ore more sub-tasks for the Front-End squad. E.g.: Include text field for Registration field
on the Form screen.
c. 1 sub-task for the PO to perform tests before handling to SIT QAs.
d. 1 story to Create Test Scenarios (which will be performed by QAs).
e. 1 story to perform integration tests (which will be performed by QAs).

GFT Agile Runbook | © GFT Technologies SE 2018 Page 10 von 32

 Estimating with the team

a. QAs will estimate the scenarios creation and integration tests sub-tasks;
b. The team will estimate development sub-tasks (Front and Back-End);
c. PO will estimate PO tests sub-tasks.

The estimation is done by informing “Original Estimate” + “Remaining Estimate” fields in weeks /
days / hours. Initially, Original and Remaining Estimate will be the same. E.g.: 2 days to complete,
2 days still remaining.
d. PO will update the parent story of sub-tasks, informing the story points. We can use as a
reference: 1 story point = 1 day.

GFT Agile Runbook | © GFT Technologies SE 2018 Page 11 von 32

 Creating Releases (Fix Versions)

Define Releases aiming the important deliveries of your project.

GFT Agile Runbook | © GFT Technologies SE 2018 Page 12 von 32

 Associating your tasks to the Releases

Linking the tasks to Milestones provides a better view of the relevant deliveries of the project.

GFT Agile Runbook | © GFT Technologies SE 2018 Page 13 von 32

 5 Sprint Planning

During this meeting – after the backlog grooming – we discuss about the activities and perform any
adjustment, if necessary.

The team is gathered to clarify any pending points and define the number of tasks to be handled in
the sprint, considering the risk margin. For example, we define 40 story points for the sprint.
Knowing that 1 story point lasts about 1 day and we have a team with 5 developers, each one will
handle 8 SP. Then we conclude that we will deliver the Product increment in 8 of 10 workdays.

Sprints time box can be from 1 to 4 weeks. For better tracking, we usually define 2-weeks sprints
always with some testable product to the PO validate

GFT Agile Runbook | © GFT Technologies SE 2018 Page 14 von 32

 Checking the Workload by Assignee

GFT Agile Runbook | © GFT Technologies SE 2018 Page 15 von 32

 6 Running the Sprint

After activating the sprint, selected activities take place in our Kanban Board.

GFT Agile Runbook | © GFT Technologies SE 2018 Page 16 von 32

 Controlling the Defects

In general, our board has the following columns:

STATUS DESCRIPTION
In Triage Defect tickets will always start in triage, when the PO will analyze and
decide:
 It is an issue on the application and needs fixes: it is directed to the
team (moved to “To Do”)
 It is not a bug: the requestor must close it or cancel it
 It is a bug from other teams (not our action): Jira moved to “On
Hold” or even closed, asking the requestor to contact the right
team.
To Do It means that the ticket is ready to be handled and can be taken by
anyone from development team.

Developer to get tasks and move to next step.

In Progress Once developer starts to work on the Jira, he/she moves it to “In Progress”
column.
On Hold Every ticket which has any kind of impediment is moved to “On Hold”:
dependency on business clarification, pending other team’s action, etc.
Ready for Fix is completed and pull request is done.
Review
Developer moves ticket to “Ready for Review”.
Ready for Pull request is fully approved and merged.
Deploy
The person that approved and merged the PR must move the ticket to
“Ready for Deploy”.
Ready for Test Ticket is deployed to CIT environment.

The person that performed the deployment must move the ticket to

GFT Agile Runbook | © GFT Technologies SE 2018 Page 17 von 32

 “Ready for Test” to be handled by PO.
Ready for SIT The ticket was previously tested on CIT successfully and now is deployed
Test on SIT.

When an issue is found, ticket is moved back to “To Do”, otherwise, PO

moves it to “Ready for SIT Test” to be handled by QAs.
Ready for UAT The ticket was previously tested on SIT successfully and now is deployed
on UAT.

When an issue is found, ticket is moved back to “To Do”, otherwise, QAs
move it to “Ready for UAT” to be handled by UAT Team.
Done When an issue is found, ticket is moved back to “To Do”, otherwise,
it is marked as done (closed) by UAT Team.

GFT Agile Runbook | © GFT Technologies SE 2018 Page 18 von 32

 Controlling New Requirements

In general, our board has the following columns:

STATUS DESCRIPTION
In Triage It means that the stories / tasks are not ready to start.

PO moves development tasks to “To Do”.

To Do The stories and sub-tasks start its flow at this step. It means that
developers can handle the tickets.

Developer to get tasks and move to next step.

In Progress Once developer starts to work on the Jira, he/she moves the development
story + related sub-task to “In Progress” column.
On Hold Every ticket which has any kind of impediment is moved to “On Hold”:
dependency on business clarification, pending other team’s action, etc.
Ready for When pull request is done, the dev sub-task must be moved to “Ready for
Review Review” by the developer.
Ready for When pull request is fully approved and merged, the dev sub-task must be
Deploy moved to “Ready for Deploy” by the person which approved and merged
the PR.
Ready for Test Ticket is deployed to CIT environment. The person who performed the
deployment must move the dev sub-task to “Ready for Test”, to be
handled by PO.

At this moment, PO also moves the test sub-task to “In Progress”.

When an issue is found, dev sub-task is moved back to “To Do” and test
sub-task is moved to “On Hold”.
Ready for SIT The ticket was previously tested on CIT successfully and now is deployed
Test on SIT. PO should move dev sub-task to “Ready for SIT Test”, to be

GFT Agile Runbook | © GFT Technologies SE 2018 Page 19 von 32

 handled by QAs.

PO also moves test sub-task to “Done” and QAs sub-task to “To Do”.

When an issue is found, dev sub-task is moved back to “To Do” and QAs
sub-task is moved to “On Hold”.
Ready for UAT The ticket was previously tested on SIT successfully and now is deployed
on UAT. QAs must move the dev sub-task to “Ready for UAT”.

QAs also moves QAs sub-task to “Done”.

When an issue is found, dev sub-task is moved back to “To Do”.

Done When the ticket is successfully tested and working fine, it is marked as
done (closed) by UAT Team.

It is important that the “Remaining Estimate” field is always updated during the flow. It will reflect on
transparent reports.

If all the tasks from the current sprint are completed – due to high productivity of the team – next
sprint’s activities / backlog can be added to the active Kanban board.

Definition of Done (DOD)

What do you consider Done? What should be done by your dev team to put the card on Done
Column?
DOD is the rules that your time create to answer this questions!
Example:
- Have the code reviews for other Devs
- Implement unit tests

In Jira, you can add these rules in the Description field of the Story

GFT Agile Runbook | © GFT Technologies SE 2018 Page 20 von 32

 7 Planning the next Sprint

During the active sprint, we are performing the grooming and moving the activities from backlog to
the next sprints (not active).

Moving tasks from Backlog to the current Sprint

GFT Agile Runbook | © GFT Technologies SE 2018 Page 21 von 32

 8 Tracking Sprint Progress

8.1 Daily Meeting

This is the most important Agile Scrum ceremony, where the team is able to check the
project/sprint progress and the risk involved.

By default, the team needs to answer the 3 below questions:

1. What did I do yesterday that helped the development team meet the sprint goal?
2. What will I do today to help the development team meet the sprint goal?
3. Do I see any impediment that prevents me or the development team from meeting the
sprint goal?

It is recommended to do the meeting in front of the team Kanban.

GFT Agile Runbook | © GFT Technologies SE 2018 Page 22 von 32

 8.2 Information Radiators

Following our default “Running Sprint Process” showed above, JIRA will provide you a couple of
charts type that you can use to visualize important information of your project.
E.g.:

Checking all reports available in JIRA

GFT Agile Runbook | © GFT Technologies SE 2018 Page 23 von 32

 Generating Burndown Chart

The best chart that you can use to monitor the sprint progress is the burndown! Besides of show
you the sprint progress, it will also highlight any scope change.

All team member must know how to ready the Burndown

GFT Agile Runbook | © GFT Technologies SE 2018 Page 24 von 32

 Generating Sprint Health Gadget

We also have the Sprint Health Gadget that shows the progress using another view:

Making the reports more friendly

In case you want to have your reports more users friendly, you can use the confluence following
the below template where will be showing all the Sprint’s information and containing links to the
Jira charts.

Important: Is a team duty manage the Sprint and the Project raising risks and keeping the tool
updated. The Agile Master duty is to audit it.

GFT Agile Runbook | © GFT Technologies SE 2018 Page 25 von 32

 9 Closing the Sprint

At the end of each sprint, we check which activities were delivered and which ones must be moved
to the next sprint.
For the planned tasks which were not completed, we provide a justification. It can be made in
confluence page.

Reporting the closure of a Sprint

Note: Performing a detailed analysis of the product to be delivered and considering the risks, the
task moves between the sprints are not supposed to happen frequently. Nevertheless, in case it
happens, it is very important to have the information clear and transparent so the client and PM
can act to resolve.

GFT Agile Runbook | © GFT Technologies SE 2018 Page 26 von 32

 10 Sprint Review

By the end of each sprint we should perform a demo of the Product Increment developed in order
to receive client/PO approval and if necessary, suggest improvements that will be performed in the
next sprints or when suitable.

GFT Agile Runbook | © GFT Technologies SE 2018 Page 27 von 32

 11Sprint Retrospective

The team now will gather to talk about:

 The problems occurred during the sprint, to avoid them from happen again. There will be action
points, each one with an owner.
 Positive points to highlight and repeat during the next sprints.
 The winner of the gamification is awarded.

GFT Agile Runbook | © GFT Technologies SE 2018 Page 28 von 32

 12 Tracking Project Progress

Depending of the type of process defined in your project, you can use some additional metrics to
track the project progress.

For example, in case you have more than 1 sprint inside a release, you can use the below Version
Report to provide you a good view of your project progress. Also, you can use the confluence
template to provide a more user friendly view to report the progress.

GFT Agile Runbook | © GFT Technologies SE 2018 Page 29 von 32

 Using Confluence Template to report the progress

Generating Version Report on JIRA

GFT Agile Runbook | © GFT Technologies SE 2018 Page 30 von 32

 13 FAQ

13.1 Does Agile really work?

Yes! But only if:

 The team is committed

 The client act as your partner, being part of the team
 The managers must support the methodology and work along with the team to achieve the best
results

13.2 How GFT builds a committed team?

We have coaches and mentors, which work along with the team, supporting during all the project
lifecycle.

Each member of the team has also his work evaluated individually and has a constant feedback
and support. All his/her weak points are identified so improvement actions can be taken and also
his/her strong points are acknowledged and highlighted as an important item for a successful
project.

13.3 What is gamification?

Gamification is the practice of using mechanisms and dynamic games to engage the team, solve
problems and improve the acknowledgement, motivating actions and behaviours during all project
lifecycle.

In GFT we usually define some actions which results in positive or negative points to the member
of the team:

 If an activity is not correctly updated in JIRA. For example, when the developer does not move
his ticket to the proper status or when Due Date is not informed = -1 point 
 When, during the development of an activity, it is proposed a solution which follow good
practices and is good for the project in general = + 1 point 

By the end of the Sprint, the winner/loser receive a symbolic (or not) prize.

GFT Agile Runbook | © GFT Technologies SE 2018 Page 31 von 32

 13.4 I need Agile help! Who should I contact?

You can send an email to Agile Excellence Center ([email protected]) or contact one of
our members described in Agile-BR confluence.

GFT Agile Runbook | © GFT Technologies SE 2018 Page 32 von 32