DOWNLOAD: Team Working Agreement Template

Download

Working_Agreements_How_To_Guide

Team_working_Agreement

Team Agreement 

The following items have been approved by and agreed upon by the Team Name, which in part, at the time of creation, consisted of the following members: (List of team members)

• Member 1 - Developer
• Member 2 - Developer
• Member 3 - Developer
• Member 4 - Developer
• Member 5 - QA
• Member 6 - QA

Should a revision of the agreed upon items, herein, be necessary, a collective vote should take place with an ‘All’ inclusive majority of the team members involvement. 

EFFECTIVE DATE Day/Month, Year

We Commit to: 

• We commit to the Agile principles
• We commit to be on time, end on time
• Will communicate with the team if you cannot make the stand-up/any meeting or will be running late
• We will always assume positive intent of our team members
• Do not interrupt others while they are sharing
• Everyone should actively contribute
• Be transparent and honest
• No phones or PCs in any ceremonies, unless you are presenting or updating JIRA in Grooming/Planning
• Commit to using Agile to ensure successful delivery of sprint commitments
• Respect the opinion(s)/input of others
• Address personal conflicts in private. Reward and give KUDOS in public
• Document PTO on team confluence page
• Log work in Jira daily
• We commit to “figuring it out” as a team
• We commit to have fun as a team!
• JIRA/Rally/Azure DevOps is our Single Source of Truth and Technology Roadmap
• Knowledge sharing provides some type of documentation
• Take some initiative on learning something new from the Subject Matter Experts

Team Meetings

• Stand-up
• Daily at EST
• 15 minutes 
• 15 to work through additional issues (if needed- parking lot) 
• Sprint Planning – First day of the Sprint.
• Sprint Demo/Review - End of the sprint 
• Sprint Retrospective - End of the sprint

Team norms 

• Don’t be afraid to ask for help 

 

• Be on time for meetings, provides a heads up to the team if you are running late

 

• Convey any delays in the project as soon as you come to know. 
• Proactively provide updates if you can’t make stand-up 
• Sprints - 2 weeks, Releases (Planning intervals) - Deployments - when needed  
• Done is defined: 
• User Story = Developed, Tested, accepted without Defects / with agreed upon Defects (See Below) 
• Each member of the Team is individually responsible for keeping the Dev and QA environment in a working state. 
• User Stories must be delivered throughout the Sprint, targeting smaller Story Points first in the beginning of the Sprint; incrementally and smartly deliver stories throughout the Sprint 
• Commitments need to be made, if User Stories are estimated and then too big once reviewed the User Story is broken into smaller units. 
• If the smaller units are not possible to be tested, then there is a tech story drafted and dependencies are noted
• User Stories need to be testable 
• The Developer is responsible for moving User story from Development → In progress → Done
• Product feedback during sprint review will be evaluated and agreed upon by development and tester to be included in the current sprint. if it is not feasible, negotiations to be done with product on removing scope to add new scope
• Backlog Refinement occurs once or twice every week - specify the schedule
• User stories have to be groomed/refined and ready by sprint planning for teams to better plan the sprint 
• Delivery team (Dev/Test engineering) will start working on groomed/refined user stories only
• User stories should be the single source of truth for both dev and test engineering. Defects will be open if the application does not comply with the user story. All changes not specified in a user story should be handed as a new user story and not defects

Scrum Team Points of contact during Available Hours 

Name	Role	Mobile Number	Available Hours (in ET)	Email
	QA Lead
	Product Manager
	Product Owner
	Dev Lead
	Scrum Master

 

Capacity plan for Initial Sprint(s)

• To be developed by the team & Scrum Master using the Capacity Team template 

Story Point Normalization

• 1 story point = < half day
• 2 story points = ½ day
• 3 story points = 1 to 3 days
• 5 story points = 3 to 6 days
• 8 story points = 2 weeks
• 13 story points = Needs to be broken down

User Story Scheduled State status

New (N) - New when a user story is created

Development (D) - When all Tasks are defined under the User Story

In progress (P) - In Progress while tasks are in progress

Completed (C) - when all tasks in the user story are complete from development and test engineering team

Accepted (A) - when this user story is accepted by the Product Owner 

Release (R) - when the user story is released to Production

GENERAL NORMS:

1. Daily Standup @ 9 am EST
1. What was done yesterday to the progress of the sprint goals?
2. What will I do today to the progress of the sprint goals?
3. Any Impediments?

1. Backlog grooming will be scheduled @ 1 PM EST on every Thursday

 Notes

1. While current sprint going team can initiate plan for next sprint so we will have better understanding of all upcoming tasks and team can start POC (proof of concept) for scripts ahead of time 
2. User Stories are not committed to unless they meet Definition of Ready
3. Once a Sprint is committed, no switching around of stories - can pull from backlog if completed early. Exceptions are tolerated in unavoidable situations
4. Tasking and estimates are done independently after the sprint planning
5. Tasks estimates and work item states should be reviewed and updated every day by the team members assigned to the task
6. Team members should reduce WIP (Work In Progress)

A COPY & A GUIDE IS AVAILABLE FOR DOWNLOAD