| IO ANALYSIS | PART III | TEAM AGREEMENTS - bdemirjian/apbr2 GitHub Wiki
| Definition of Ready | ||
|---|---|---|
|
Purpose:
A team-generated set of guidelines for PBIs to be considered or accepted into the sprint backlog Who Participates: Whole Team |
||
| Inputs | Activites | Outputs |
|
Product Backlog Items Relevant retro action items Refinement User stories |
Refinement Newly formed teams may use the first refinement session to outline what information would be useful to be able to work on an increment Write their ideas down and make it visible For subsequent refinements, the team uses their Definition of Ready guideline to assess the content of the ticket Add or modify the team definition of ready as needed Retrospective Teams may take some time in their retro when it's timely, to assess their definition of ready by asking questions like: Is it working for us? How did the guideline help our team? Did the guideline harm or hinder the sprint? Were we still able to practice concurrent engineering? Is the content in our sprint backlog items "just enough"? Evaluate recently completed stories by asking, is this statement true? "I had just enough information to begin the work and anymore would have been wasteful." Adjust your Definition of Ready accordingly |
A visible and regularly used Definition of Ready Product Backlog Items (updated) |
| Tools & Templates | Success Tips | Learn More |
|
Jira |
Avoid using the Definition of Ready as a stage-gate. Keep in mind it's a guideline that can be useful for teams to seek clarification on a particular increment. It's up to the team's discretion if a certain guideline is not needful to have prior to pulling it into a sprint. If they were wrong, then use that as a learning opportunity for the team to carefully consider the Definition of Ready next time. It may be useful to add an automation to your JIRA project that will pre-fill your JIRA tickets on creation with your team's definition of Ready Common Definition of Ready guidelines*: User story or description of business value Acceptance criteria or conditions of satisfaction UX/UI prototypes Assumptions Technical comments Relative sizing estimates or Story Points Testing guidance Generally follows the INVEST criteria Replication steps (for bugs/defects) Expected outcome (usually for bugs/defects) Keep it simple and select a few things (e.g. understood by team, has acceptance criteria, has been sized) *Note: these are just the ones I've encountered, feel free to add to this list |
Scrum Inc: Definition of Ready Mike Cohn's caution regarding Definition of Ready Scrum.org: Definition of Ready Scrum Alliance webinar: Making your User Stories Ready |
- Scrum Inc: Definition of Ready
- Mike Cohn's caution regarding Definition of Ready
- Scrum.org: Definition of Ready
- Scrum Alliance Webinar: Defining Done, Ready, and NO
- Scrum Alliance webinar: Making your User Stories Ready
| Definition of Done | ||
|---|---|---|
|
Purpose:
The team agrees on, and displays prominently somewhere in the team room, a list of criteria which must be met before a product increment “often a user story” is considered “done”. Failure to meet these criteria at the end of a sprint normally implies that the work should not be counted toward that sprint’s velocity. Who Participates: Whole Team |
||
| Inputs | Activites | Outputs |
|
Facilitator (Scrum Master/Agile Coach) suggested guidelines for Definition of Done Team generated guidelines for Definition of Done |
The best way to come up with a Definition of Done for your team is to sit together as a team and come up with a checklist that the whole team agrees upon. 1. Ask the questions, "What tasks would we always want to do?" and "What kind of checks would we always make?" before pushing code to real customers ("pushing to production"). 2. Consider any previous times that some team members referred to work as "done" but other team members felt that it was "not done." What were the differences? Are those items that should be added to your Definition of Done? 3. If you have a dedicated Quality Assurance (QA) team that does all the testing of your products before release, what do they consider as important? 4. Many teams write automated checks (or tests) on their codebase so that they know if some new code breaks any of the logic of the old code. If you have automated tests that run on your codebase, you will probably want to include that "no new code breaks any old code." All tests should pass! 5. Do you have any automated systems that run on your code? Some tools like Code Climate can even provide you with a quality score and can scan your code for bad practices, such as repeated chunks of code! If you have such tools, they can be incorporated into your Definition of Done. |
Definition of Done Post them on a wall where everyone can see them Team holds each other accountable to adhere to the Definition of Done |
| Tools & Templates | Success Tips | Learn More |
|
Canvas Large sheet of post-it paper Markers & Post-it notes |
Expected Benefits The Definition of Done provides a checklist which usefully guides pre-implementation activities: discussion, estimation, design The Definition of Done limits the cost of rework once a feature has been accepted as “done” having an explicit contract limits the risk of misunderstanding and conflict between the development team and the customer or product owner Common Pitfalls Obsessing over the list of criteria can be counter-productive; the list needs to define the minimum work generally required to get a product increment to the “done” state Individual features or user stories may have specific “done” criteria in addition to the ones that apply to work in general If the definition of done is merely a shared understanding, rather than spelled out and displayed on a wall, it may lose much of its effectiveness; a good part of its value lies in being an explicit contract known to all members of the team |
An Exercise for Defining Done |
| Team Working Agreement | ||
|---|---|---|
|
Purpose:
Any group structure needs to define how they will work together and what's expected. They can be assumed or learned through trial-and-error. The most effective approach is to set time to purposely draft desired positive behaviors in the working agreement as a team. Who Participates: Scrum Team |
||
| Inputs | Activites | Outputs |
|
Facilitator suggested guidelines for working effectively Team generated guidelines for working effectively List of behaviors that are ok and not okay on the team (generally keeping positive is helpful, but if there is a strong boundary it's okay to make it explicit) Considerations: Do we want to establish core hours? If so, what would they be? When is our daily standup? What happens if you can't make it? Cellphones and meetings, what's respectful for the team? What's our definition of done? How will we make decisions? Majority-rules? Consensus? What happens when we disagree? How will we resolve it? How can we show each other respect? What if we're feeling unheard? How can we get help? |
Team working agreement creation Creation method will depend on how familiar the team is with working agreements If the team has no experience with creating a working agreement, you may need to generate general guidelines and have them choose the ones they'd like to enforce on the team (if they're really into it they may rewrite them to fit their context!) If the team has some experience but is having a hard time coming up with a solid list, you may need to "prime the pump" by bringing in some suggested agreements (don't worry if they don't want to add them to the agreement, it's theirs not yours) If the team has a lot of experience with creating a working agreement, try something new template or method, like the working agreement canvas. This may generate some new or specific agreements they haven't previously considered. Updates to working agreement When a change happens on the team, whether you gained or lost teammates or the team learned something new – update the team agreement It's meant to be a living document – refer to it frequently and update it as needed |
Post them on a wall where everyone can see them Hold teammates accountable for the behaviors they committed to do |
| Tools & Templates | Success Tips | Learn More |
|
Link Scrum Inc Working Agreement canvas Large sheet of post-it paper Markers Post-it notes |
Working agreements provide value to the team if they are referred to frequently and expected The agreement needs to be public and visible to the team: put it on the wall, print it out on a card, link it on the dashboard, whatever will help your team keep it visible The Scrum values are a great foundation to base your agreements on |
How to Guide |