Team Working Agreement

ALDI – Tredence Engagement

 Contents
1. Scrum Project ------------------------------------------------------------ 2

1.1 Tredence Project Team (Incomplete) ------------------------------------- 2

1.2 Assignment Matrix ----------------------------------------------------- 2

1.3 Scrum Team Roles and Responsibilities ----------------------------------- 2

2. Creating Jira Issues, Workflow --------------------------------------------- 3

2.1 Jira Issues ------------------------------------------------------------ 3

2.2 Jira Workflow --------------------------------------------------------- 4

2.3 Workflow for ALDI ------------------------------------------------------ 4

2.5 Mandatory Fields in User Story ------------------------------------------ 6

3. Creating an Epic --------------------------------------------------------- 6

4. How to Estimate, Tools and Technique -------------------------------------- 7

4.1 User Story Estimation --------------------------------------------------- 7

4.2 Tools and Technique --------------------------------------------------- 7

5. Scrum Events ------------------------------------------------------------ 8

5.1 Sprint Planning -------------------------------------------------------- 8

5.2 Daily Scrum (Standups) ------------------------------------------------ 9

5.3 Sprint Review/Demo --------------------------------------------------- 9

5.4 Sprint Retrospective -------------------------------------------------- 10

5.5 Product Backlog Refinement/Grooming --------------------------------- 10

6. Jira Artifacts ------------------------------------------------------------ 11

6.1 Acceptance Criteria ---------------------------------------------------- 11

6.2 Definition of Ready ---------------------------------------------------- 12

6.3 Definition of Done ----------------------------------------------------- 12

7. Team Agreement -------------------------------------------------------- 13

© Copyright 2023, Tredence. All Rights

1
Reserved
 1. Scrum Project
1.1 Tredence Project Team (Incomplete)

Project Sponsor Amy Hyet

Stakeholder Amy Hyet, Kyle Flanagan, Tim Morris and Mike Conley
DE - Vipul Bhatnagar
Product Owner
CXM – Abhinav Kant
Scrum Master Praveen Poojary
DE- Tanushree
Technical Lead
CXM - Niharika
DE –
Developer CXM -

1.2 Assignment Matrix Commented [MM1]: @Praveen Poojary: Could you

elobarate on this?

Issue Epics Story Task

Type

Track Reporter Assignee Reporter (Lead) Assignee Reporter Assignee

DE Vipul Tech Lead Tech Lead Developer Developer Developer

Bhatnagar

CXM Abhinav Tech Lead Tech Lead Developer Developer Developer

Kant

1.3 Scrum Team Roles and Responsibilities

Stakeholder ALDI – Amy Hyet, Kyle Provide Input - This helps in shaping the Product
Flanagan, Tim Morris Backlog and ensuring that the delivery aligns with
and Mike Conley their needs and expectations.

Tredence – Aman, Participate in Sprint Review: Stakeholders are invited

Anuj Agarwal, Satish to the Sprint Review, where they can inspect the
increment and provide feedback. This helps in
adapting to delivery based on their input.

© Copyright 2023, Tredence. All Rights

2
Reserved
 Product Owner ALDI - Tim Morris and Prioritize items in the Backlog based on business
Conley Mike value, customer feedback.

Tredence - Vipul, Ensure that the team understands the items in the
Abhinav Backlog and their acceptance criteria.

Be available to the Development Team to answer

questions and provide clarifications during the
Sprint.

Accept or reject work results at the end of each

Sprint based on the Definition of Done.

Scrum Master ALDI – Andrew Facilitate Scrum events, including Sprint Planning,
Daily Standup, Sprint Review, and Sprint
Tredence - Retrospective.
Praveen/Megharaj
Identify and help remove obstacles or impediments
that hinder the Development Team's progress.
Development ALDI Design and implement features, conduct testing,
Team DE - Charu, Niraj, and ensure that the increment meets the Definition
Krishel of Done.
CXM – Sunitha, Rolan
Select items for the Sprint Backlog (derived from the
Backlog) during Sprint Planning based on the team's
Tredence – DE and capacity.
CXM
Collaborate to break down work into smaller tasks
and user stories.

Participate in the Daily Standup to share progress

and address impediments.

2. Creating Jira Issues, Workflow

2.1 Jira Issues
Organizations may have different types of issues depending upon their suitability/ needs.
Jira administrators can efficiently customize this field.

1. Epic: This is normally a huge issue which is ideally broken into several small issues. It can
take several sprints to complete the main epic issue in an agile environment.
2. Story: Entire user stories about a feature that could be a type of issue (Tag)
3. Bug: This is any defect or deviation found.
4. Task: This is more of a configuration or analysis issue. For example, setting up proper
configurations can be a task.

© Copyright 2023, Tredence. All Rights

3
Reserved
 2.2 Jira Workflow Commented [AA2]: Change in section is not
clear? Can we number the section

Commented [PP3R2]: Done. I have Numbered all

section, Available in Table Content

2.3 Workflow for ALDI

1. An issue created in JIRA is always in the status “To-Do” upon creation. Commented [AA4]: It can also be opened as
2. The workflow stages for ALDI are - backlog, not sure if it is Jira or ADO. Fine with this
too

Create –> To Do -> Ready for Dev -> In Progress -> Under Review -> Done -> Commented [PP5R4]: All Tickets are considered
Backlog, It is an Item where as "To-Do" will be
Completed.
state of backlog

3. Only Admin will be able to choose this and once chosen, it cannot be changed and Commented [AA6]: Who is the admin? Andrew or
all the issues under the project will go through the same workflow. Krishel? Will Praveen or Megh have admin access

4. When Jira is created it will be in “To-Do” State, Post Refinement of Jira it will move to Commented [MM7R6]: Need to define, proposed
“Ready for Dev”. names would be Andrew/Praveen

5. When the “Start Progress” button is clicked the issue status changes to “In Progress.
6. Clicking on the “Workflow” button will display you a list box of the next stages that
an issue can go to.
7. If the issue needs to be set to “Done” directly, there is a “Done” button available. On Commented [AA8]: What is the concept of
clicking it you will be able to choose the reason for saying the issue is Done. Definition of Done

Definition of Done will be defined by the leads during the sprint planning session. Commented [PP9R8]: Update in Below Section
,Basically a checklist to make sure we are
capturing all aspect before closing ticket. For Any
Ticket to be consider done, It needs to clear all
checklist

© Copyright 2023, Tredence. All Rights

4
Reserved
 2.4 Creating an Issue

1. Click on ‘+’ (‘Create’) toolbar button.

This will display a screen/page as shown in the image below. Commented [AA10]: If we have Jira in Tredence,
then we can use the same for all sections above
also

Commented [PP11R10]: In Tredence we only have

ADO, I will update screenshot from ALDI post
Epic Details working on workflow
Issue Type

Acceptance Criteria in Bullet

Points

Definition of Done Acceptance Criteria in Bullet

Points

Definition of Done – Checklist to

Ensure Ticket is Completed

2. Enter as many mandatory details and other data as possible on the “Create issue” page.

3. Click on the “Create” button. This will generate a unique issue ID. The ID will consist of a project
identifier concatenated with numeric digits.

In the above Example, the project chosen is ‘Tredence Analytics’, hence the ID is ‘TA-6’.

• Once the issue is created, thereafter it can be searched using the issue ID.

© Copyright 2023, Tredence. All Rights

5
Reserved
 2.5 Mandatory Fields in User Story

Issue Summary/ Always start with a verb – Create, Develop, Edit, Fix, Enhance, Refactor.
Heading This is to ensure that the resource working on it has a direction on what is Commented [AA12]: Sudden change in font and
expected only by reading the summary itself size of text. Should be consistent across the doc

Commented [PP13R12]: Fixed formatting

<DE/CXM> - <Issue Heading>

Description Filed Syntax -

• (“As a [persona], I [want to], [so that].”)
feel free to include email conversations, Link Jira tickets, attach architecture
diagram/Wireframe

Acceptance Acceptance criteria could establish a boundary that helps team members to
Criteria understand what’s included and what’s excluded from the scope of the user
story.

Expected Impact of story on business level and How its Contributing to Epic
Business Impact

Estimation To estimate the relative size and complexity of user stories or tasks we will use
Technique story point estimation, and this will be done as per Fibonacci Series.
• 1,2,3,5,8,13…And so on
• Assign Story point based on level of understanding and time required
to implement.
• Any user story more than 8 Story point can’t be taken in sprint without
refinement.

Tags 1.TreDe 2.TreCXM 3. Blocker 4.InProgress 5.Completed

3. Creating an Epic
Commented [AA14]: Please provide an example
for each

Commented [PP15R14]: Added Example of Actual

Epic Name/Title A clear and descriptive name for the epic that provides a quick Epic from Project

overview of its scope and purpose.

Syntax:
1. <AE(ALDI Engagement)> FY23Q4 <Epic Name>

Eg: 1. AE FY23Q4 - Platform Design and Framework Build

© Copyright 2023, Tredence. All Rights

6
Reserved
 Epic Description A detailed description of the epic, including its objectives, goals,
and any specific information that helps stakeholders understand
its significance and purpose.

Epic Owner Designate a product owner or responsible individual/team who

will oversee the epic's development and ensure its alignment with
the overall project goals.

Epic Priority Indicate the relative importance of the epic within the project's
overall backlog. This can help in prioritization and planning.

Epic Business Value Define the expected value or benefits that the epic is expected to
deliver to the organization or end-users. This helps in assessing its
importance.

4. How to Estimate, Tools and Technique

4.1 User Story Estimation
1. The estimate techniques we will be using in ALDI Project will be Story Point. Commented [AA16]: Option needs to be
2. It is a Relative Estimation and The Numbering system we will be using is discussed and finalized with Aldi Teams

Fibonacci series i.e., 1,2,3,5,8.. Commented [PP17R16]: Noted.

3. These number series represent relative size of work and account for complexity
in terms of implementation.
4. Benchmark would be any developer completing 8SP in each sprint of 10days.
i.e., 6-8hrs of work would account for 1 Story Point.
5. Please go through the YouTube video to learn more about story point
estimation. YouTube URL: https://youtu.be/VsSaolMtkKU?si=564Z5JyT_pQfGp5F

4.2 Tools and Technique

1. Planning Poker Technique will be used during sprint planning, where we will bring
consensus amongst sprint team.
2. Each member from the team will estimate user stories in story point based on their
understanding of implementation and any variance is thoughts will be cleared with
discussion.

© Copyright 2023, Tredence. All Rights

7
Reserved
 5. Scrum Events
5.1 Sprint Planning
• Time Box: Up to 2 hours for two weeks of sprint
• Participants: Scrum team, SMEs, and Stakeholders

Sprint Planning initiates the sprint by laying out the work to be performed. The collaborative
work of the entire Scrum team creates this resulting plan.

There are four critical elements of a sprint planning ceremony that you’ll want to touch on:

• Set goals for the sprint.

• Define the scope of the sprint.
• Address concerns
• Plan out the sprint.

How to Run a Sprint Planning Meeting

1. Gather your team together and check-in. Remind the team of the purpose of Sprint
Planning: to identify the next two weeks’ worth of work.
2. Pull the Story from the top of the Product Backlog to the Sprint Backlog.
Ask the team the following questions:
▪ Is it straightforward how to complete the Story? If not, ask for suggestions from
the team.
▪ Can the Story be completed in 2 weeks? If not, divide it into smaller stories.
3. Assign the Story to the owner. Choose which role is responsible for completing it and
ask them if they can complete the tasks during this Sprint.
4. If the team can accept more, go back to step 2.

Effective Sprint Planning

1. User stories can be broken up into smaller tasks & assigned during sprint planning so
that everyone knows what they’re held accountable for.
2. Encourage the team to sketch tasks, bugs, and items required during this meeting. It
should be an extremely collaborative ceremony.
3. Factor in any holidays, events, or days off.
4. Take risks into account.
5. Consider breaking longer meetings into two to avoid unbearable time at the screen.

© Copyright 2023, Tredence. All Rights

8
Reserved
 5.2 Daily Scrum (Standups)
• Time Box: 30 - minutes/day
• Participants: Scrum team
The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the
Sprint Backlog as necessary, adjusting the upcoming planned work.

These are the three key areas you’ll want to cover:

1. Discuss what has already been done: Establish what your team has accomplished
up to this point and how it led to where they currently are.
2. Discuss what’s next: Find out where your team plans to head once they’ve done
today’s work.
3. Discuss any obstacles or pitfalls: The team is to mention any issues that are
affecting the completion of their work.

Effective Daily Scrum Meetings

1. Hold the meeting at the same time each day of the week (typically in the mornings)
and do what you can to make this as routine for the scrum team as possible.
2. If your team is distributed, leverage video conferencing software so the team can still
see each other.
3. If something comes up in this meeting that warrants a more extended conversation,
encourage the team members to sync up as soon as the Daily Scrum wraps up to
determine when they want to collaborate. It could be immediately after the meeting
or later in the day.
4. The Scrum master should be willing to tell team members when they are getting off-
topic and talk about the items in order of priority.
5. The Developers should start owning the Daily Scrum meetings, not the Managers.

5.3 Sprint Review/Demo

• Time Box: 1.5 - hours for two weeks of sprint
• Participants: Scrum team, SMEs, and Stakeholders

The purpose of the Sprint Review is to inspect the outcome of the sprint and determine future
adaptations. The Scrum team presents the results of their work to key stakeholders, and
progress toward the Product Goal is discussed.

The sprint review ceremony has three main objectives:

1. Demonstrate the Sprint backlog tasks completed to the product owner and
stakeholders.
2. Solicit feedback from the project stakeholders.
3. Team updates the product backlog based on the discussion.

© Copyright 2023, Tredence. All Rights

9
Reserved
 Effective Sprint Reviews

1. Block out enough time.

2. Focus demonstrations on value.
3. Actionable feedback received during the Sprint Review should be converted into new
product backlog items for later prioritization and discussion.

Focus the Sprint Review on user experience and business value.

5.4 Sprint Retrospective

• Time Box: 1 - hours for two weeks of sprint
•Participants: Scrum team
The purpose of the Sprint Retrospective is to plan ways to increase quality and
effectiveness.

These are the core topics you should focus on:

1. Discuss what was successful about the sprint.

2. Discuss what could’ve been better during the sprint.
3. Discuss what can be improved during the next sprint.

Effective Sprint Retrospectives

1. Create a comfortable space during the retrospective.

2. Revisit previous suggestions to determine whether the team should keep doing them.
3. Create a plan with specific improvements to be carried out during the next sprint.
4. Take turns facilitating the scrum retrospective.
5. Vote on the Best Ideas.
6. Document what was discussed and update your product backlog

5.5 Product Backlog Refinement/Grooming

Product Backlog Refinement is breaking down and further defining Product Backlog items
into smaller, more precise items. This activity is ongoing to add details, such as a description,
order, and size.

Key things to be done during the backlog refinement:

1. Eliminate and Add User Stories

2. Update Priorities and Estimates
3. Splitting User Stories

© Copyright 2023, Tredence. All Rights

10
Reserved
 Effective Product Backlog Refinement

1. Let the Team Lead add backlog items to create ownership.

2. Set Aside dedicated time for refinement.
3. Order the user stories and features based on the highest business value always on
top.
4. Building a D.E.E.P. Backlog

• Detailed Appropriately
• Estimated
• Emergent
• Prioritized

6. Jira Artifacts
6.1 Acceptance Criteria

Acceptance criteria are the conditions that must be satisfied for a product, user story, or
increment of work to be accepted. Acceptance criteria are either met or not met; they're
never only partially fulfilled.

Acceptance criteria do not focus on “how” a solution is reached or “how” something is made.
Instead, they illuminate the “what” of the work you are doing.

Acceptance Criteria are often expressed as a set of statements. These statements should
be:

1. Clear so that everyone understands them.

2. Concise, so that there’s no ambiguity.
3. Testable or verifiable
4. Focused on providing customer-delighting results.

Example - Scenario-Oriented Acceptance Criteria

As the name suggests, the scenario-oriented format is the acceptance criteria type that
comes in the scenario form and illustrates each criterion. It is approached through the
Given/When/Then (GWT) sequence that looks like this:

1. Given some preconditions.

2. When I do some action
3. Then I expect some result

© Copyright 2023, Tredence. All Rights

11
Reserved
 6.2 Definition of Ready

A definition of ready (DoR) is used to determine whether work on a task is ready to be started.
Before teams assign a task or user story in a sprint, it must be sufficiently well described and
understood by team members. A definition of ready serves as a checklist of criteria to help
facilitate a team's decision to begin working on a new task.

Sample DoR Checklist (Will be updated after connecting with the team)

1. User stories have business value.

2. Story is prioritized.
3. User story is clear and well-defined.
4. Acceptance criteria are defined.
5. User story dependencies/risks have been identified and mitigated.
6. The development team has estimated the user story.

6.3 Definition of Done

The definition of done (DoD) is a collection of criteria/checklist that must be completed for
a project/task to be considered “done.” It is essentially a checklist used by the Scrum team
to create a shared understanding of what is required to make a product releasable.

© Copyright 2023, Tredence. All Rights

12
Reserved
 Sample DoD Checklist (Will be updated after connecting with the team)

• Code Development
1. Code development is completed.
2. Code changes are reviewed for coding standards.
3. The functionality should be tested and should work as expected.
4. Documentation, if any, is completed.

• Spike/Discovery
1. The requirement is analyzed thoroughly.
2. The outcome of the spike is a design/framework.
3. The design must be shared with the clients and get it signed off (optional)
4. Post approval, the design must be documented.

7. Team Agreement
1. For a two-week sprint, the maximum number of story points for a story will not be
more than 8.
2. Stories/tasks should be updated daily before the stand-up.
3. Don't wait for a specific meeting to voice any issues/blockers. Use the team chat
to notify and tag relevant people.
4. If, due to unforeseen circumstances, a feature delivery cannot be completed as
planned, highlight the same as early as possible so that it can be flagged as
program risk and communicated to the client at the earliest.
5. Before sprint planning, ensure that any tasks required to be completed by another
team member (Dependency) have been communicated to them. This way, the
other team can allocate a specific capacity for this work.
6. All tasks must be marked as done, and the remaining hours must be updated as
"0" to consider the task closed.
7. Planned leaves should be communicated at least two sprints in advance and
updated in Leave Tracker.
8. Peer review has been done (If applicable).
9. Informing in advance if any scrum call cannot be attended and letting others
know about the current progress on the team's chat.
10. Need to have a video call every week.

© Copyright 2023, Tredence. All Rights

13
Reserved
© Copyright 2023, Tredence. All Rights
14
Reserved