Team Practices Group/Best Practices Handbook

The Team Practices Group (TPG) was dissolved in 2017.

Information on this page has been collected or prepared by members of the Team Practices Group for experimentation, discussion, and validation. It is not meant to be authoritative or prescriptive for WMF staff or community members.

Purpose

This page documents TPG's recommendations for how to execute various common activities within the WMF environment. These are based on feedback from WMF staff and stakeholders, best practices in software development, and TPG members' experiences. They are intended to serve as a starting point for Wikimedians.

Common Meeting Types

Daily Standup

This is a daily meeting to coordinate activity. This meeting format is suitable for teams that work together on the same subject.

Mode

Information Sharing

Artifacts

None. (no notes, no agenda)

Timing

Daily, preferably in the morning. Fifteen minutes maximum.

Procedure

1. Use a recurring Google Meeting with fixed hangout.
2. One person begins (this could be the final person to join)
   1. That person describes what they have accomplished in the last day, what they are planning to do today, and anything that is affecting their work or may be urgent news to other people on the call.
   2. Other people do not speak other than to ask clarifying questions.
   3. The person picks someone else to go next.
3. Continue until everyone has spoken.
4. The stand-up is over. Optional discussion may continue for all interested parties.

Notes

An effective daily standup is focused on information sharing, not problem-solving. Therefore, it can be most effective to allow each person in the standup to speak before anyone asks questions or offers comments. Alternately, teams may allow clarification questions; in this case, teams (and ScrumMasters) should pause any ongoing conversation and and ask team members to continue with the standup and hold detailed discussion until after. After everyone has spoken, the Standup is over and the team may decide who should remain for further discussion.

With extreme geographical split

If there is no convenient time for all team members to participate in one standup, options include:

• Have two standups, at different times ...
  • ... and have one person attend both and carry information from the first to the second
  • ... have the first standup send a brief report to the second one
• Rotate the time of the standup so that everybody takes a turn meeting at a locally inconvenient time

"Last Week's Notes" Project-based Status and Planning Meeting

This is a weekly to monthly meeting to coordinate activity. This meeting format is suitable for groups of people that do not otherwise meet as a group on this subject.

Mode

Information Sharing, Work identification

Artifacts

Ordered list of projects and notes, in a wiki page.

Timing

One hour maximum. Every one to four weeks, depending on the volume of information.

Procedure

This meeting treats the scope of work for a project as a collection of non-overlapping sub-projects.

1. Review last meeting's action items

Starting at the top of the list of sub-projects:

1. Is there any other sub-project that is more important? If so, move that to the top, or make a fresh sub-project if necessary, and do it first.
2. If this sub-project is marked done in the notes, confirm and delete.
3. Anyone with new information about the sub-project presents that new information.
   1. Anyone can ask clarifying questions as appropriate.
4. Any outstanding questions or next actions identified in the previous notes are re-asked or re-checked.
   1. Any open questions that cannot be instantly answered are flagged for followup after the meeting.
   2. If there are any problems that require followup, all interested parties indicate their interest and someone is designated to lead followup after the meeting.
5. Notes from the last meeting are overwritten with fresh notes from the current meeting
6. If the sub-project does not require any further attention from this group, that is noted.

Repeat until all sub-projects are reviewed or time is up.

Specialized Meeting Types

See Workshop Planning#Activities for a variety of detailed meeting designs applicable to specific needs.

Retrospectives

• Scrum Sprint Retrospective
• Five finger retrospective

Scrum Charts

Several charts provide essential visibility into the performance of Scrum teams. Charts provide a relatively objective, repeatable, quantifiable understanding of what and how the team is producing. Charts can also help isolate problem areas with the process. However, charts are also strongly limited in their explanatory power, and should only be used as one tool among several for understanding and changing process. At a minimum, Scrum teams should maintain current Sprint Burnup, Product Burnup, and Velocity charts. Cycle Analysis and Bug Trend charts are also recommended.

Use and Limitations of Charts and Data

• Activities in software are inherently unpredictable and hard to measure. Uncertainty of 50% or greater is typical. This should always be taken into account when interpreting charts, by showing error bars and uncertainty and by remembering that "reality" may be quite divergent from data.
• Measuring something can provide incentive to change it. Incentives to change a thing being measured may lead people to change the measurement itself, in ways that don't benefit the thing being measured. This can be intentional but it can also happen through bias and wishful thinking. Effective use of numerical measurements in judging peoples' work requires mutual trust that the measurements will not be tampered with, misused, or abused. For example, comparing the raw velocity of two different Scrum teams may incent team members to inflate their estimates.

Software Work Breakdown in Scrum

High-level work breakdown

The basic Catch-22: How long will it take vs what do you want?

In project estimation, there is a basic contradiction: the customer wants to know how long the work will take before they commit to a scope of work, and the engineers need a scope of work to produce a forecast. One way to break through this is to do quick, bulk estimation of the broadest scope of work, and then cut from there.

Working with big backlogs

The fundamental problem with using stories for work breakdown is that stories must be small enough to implement, but for any significant software project, stories that small will number in the hundreds or thousands, which makes things like prioritizing or just reading the backlog very time-consuming. There are two main approaches: Rolling up into Epics, and Grouping by Features. It is also possible to use a hybrid approach, where a project has some Epics, but also has some areas where large numbers of stories have been broken down and grouped by feature. (n.b. the usage of "Epic" here closely conforms to Scrum common practices; the usage of Feature may be more idiosyncratic, but it's not clear there is consensus on a useful definition of Feature in Scrum.)

(What about grouping by priority/timeline? I was on a project that had thousands small stories,, split into about 5 buckets, where the buckets ranged from "this version" and "next version" through "probably never".)

Identifying Sagas and Epics and bulk-estimating them

In the first approach, the team works with some extra-big Stories (Epics) that later get broken down into more useful Stories via progressive elaboration, slowly enough that finished stories can disappear at a similar rate, leaving the total number of open Stories/Epics manageable (i.e., under 100 or under 50). An Epic could be simply any story that is 100+ or 40+ points, or Epics could be a distinct type of entity. Sagas can be used to provide a third level of scaling. This approach is simpler and faster.x

(This is described as a paper process; it may be computerized in a spreadsheet. Ideas on how to implement in Phabricator are pending.)

1. Identify the key results desired for the next major milestone.
2. Prepare the Breakdown board:
   1. Make a column for each different functional area/team role for the software. This will vary depending on the focus of the team and software. Each column will contain work that is relatively independent from other columns, because different people do it or because it has few dependencies to other columns. Examples: Graphic Design, CSS/HTML, server-side functions, browser functions, Database, Performance, Automated Testing, Packaging, Documentation. The purpose of columns in this exercise is to spread out the cards on the wall so they aren't in one big lump; the columns may not be necessary after all sagas are assigned owners.
   2. Make rows based on level of effort bucketing used by the team. Typically either T-shirt sizing (S/M/L/XL) or Planning Poker (1,2,3,5,8, etc to 100)+
3. For each key result, identify the work necessary in each column to reach the result and write each piece of work on a different card. This may happen in a group during a meeting, or the Product Owner (possibly with one or more developers) could prepare the cards in advance. Balance these guidelines:
   1. Each distinct piece of work that can be completed independently of other work should get a card. Consider stubbing and other methods of limiting dependencies during development.
   2. Work that must be done by different people or teams should generally get different cards.
   3. Have as few cards as possible.
   4. Each card should have enough information that someone who didn't write it, but is on the same team, can pick it up and understand it, possibly with a few clarifying questions.
   5. To be useful, the total number of cards should be around 50 or less.
4. From cards of the most common column, identify one card that seems to be "medium" effort, and put it on the wall at the appropriate column and row.
5. Put all of the other cards up in level of effort rows relative to the first card. Some techniques to do this:
   1. Lead Dev puts the cards up one at a time, asking questions of the Product Owner. This method is faster, but requires that the Lead Dev be able to produce estimates consistent with what the whole team would estimate. This method has the least amount of discussion, which may be good or bad.
   2. Work in Shifts.
      1. Team members claim different sections of wall (different columns) in groups of two or three.
      2. Each small group puts up all cards for those column.
      3. Small groups switch to different areas, review all cards on the wall, and note which ones they think are misplaced.
      4. Small groups gather back in the larger group to discuss disagreements and reach consensus.
      5. Repeat until all small groups have reviewed all Sagas.
   3. If a card is unclear, the Product Owner should make a new card or cards that addresses questions.
   4. If a card is judged too big, the Product Owner should split it into two or more cards.
   5. Anyone can create a new card to capture work that is not included in any of the other cards.

This will produce a list of Sagas that should comprise all work necessary to produce the key result. A rate of 20 to 40 cards per hour for one lead dev doing estimation, or more for groups of developers, seems like a reasonable balance between speed and quality.

Identifying Stories grouped by Features and bulk-estimating them

In the second approach, team breaks out as many Stories as possible, with each Story as small as possible. Hundreds of Stories is typical. The team also identifies a list of fairly high-level features, maybe a dozen or two dozen, and assigns all Stories to Features. Planning and Forecasting are then done by grouping and filtering by Feature. This approach is more accurate, but more time-consuming both initially and throughout the life of the project.

1. Identify the key results desired for the next major milestone.
2. Prepare the Breakdown board:
   1. Make a column for each different major Feature of the software. This will vary depending on the focus of the team and software. Each column will contain work that is relatively independent from other columns, because different people do it or because it has few dependencies to other columns. Examples will be very particular to different programs. E.g., for a real estate website, "Lists of Rental", "Maps", "Geocoding input", "Accounts", "Payment", "Shopping Cart", "Matchmaking". Horizontal functions such as documentation, security, etc, may be mixed in or may have their own columns. "Help", "Loading Time", "Security". The columns will identify the Feature for each Story, which is a permanent property of the Story.
   2. Make rows based on level of effort bucketing used by the team. Generally use Planning Poker (1,2,3,5,8, etc to 100) instead of T-shirt sizing.
3. For each key result, identify the work necessary in each column to reach the result and write each piece of work on a different card. This may happen in a group during a meeting, or the Product Owner (possibly with one or more developers) could prepare the cards in advance. Balance these guidelines:
   1. Each distinct piece of work that can be completed independently of other work should get a card. Consider stubbing and other methods of limiting dependencies during development.
   2. Each card should be a piece of work small enough to meet the Scrum standards of the team (for example, "doable by 2 people in 2 weeks or less")
   3. Work that must be done by different people or teams should generally get different cards
   4. Each card should have enough information that someone who didn't write it, but is on the same team, can pick it up and understand it, possibly with a few clarifying questions.
   5. If a card belongs to two Features, try to break it down further, but some cards may always belong to two Features.
   6. This approach may product hundreds of cards or more.
4. From cards of the most common column, identify one card that seems to be "medium" effort, and put it on the wall at the appropriate column (which Feature) and row (Level of Effort).
5. Put all of the other cards up in level of effort rows relative to the first card. Some techniques to do this:
   1. Lead Dev puts the cards up one at a time, asking questions of the Product Owner. This method is faster, but requires that the Lead Dev be able to produce estimates consistent with what the whole team would estimate. This method has the least amount of discussion, which may be good or bad.
   2. Work in Shifts.
      1. Team members claim different sections of wall (different columns) in groups of two or three.
      2. Each small group puts up all cards for those column.
      3. Small groups switch to different areas, review all cards on the wall, and note which ones they think are misplaced.
      4. Small groups gather back in the larger group to discuss disagreements and reach consensus.
      5. Repeat until all small groups have reviewed all Sagas.
   3. If a card is unclear, the Product Owner should make a new card or cards that addresses questions.
   4. If a card is judged too big, the Product Owner should split it into two or more cards.
   5. Anyone can create a new card to capture work that is not included in any of the other cards.

Alternative (lightweight) approach to high-level breakdown

This is best for shorter time horizons (up to 6 months), and has been most effective with smaller teams (up to about 5 developers). Whenever possible, the goal should be to consider a shorter horizon, such as 1 to 3 months. An unrelenting focus on MVP (Minimum Viable Product) is extremely helpful.

1. Create a tentative plan
   1. Product Owner determines the planning horizon, and rough capacity of the team in that timeframe.
   2. Product Owner identifies a set of 5-10 high-level, user-facing, cross-functional features ("Sagas").
   3. Team Lead reviews the Sagas for feasibility, and performs very rough "order of magnitude" estimates.
      1. Ideally this is a conversation, and Sagas would be added, removed, and revised as a result
      2. Sagas smaller than a few person-weeks are probably really Epics (which is fine).
      3. Split or reduce the scope of any Sagas that are estimated to be more than about a quarter of the entire release, or which have too much uncertainty to be reasonably estimated to an order of magnitude.
   4. Product Owner uses past velocity to choose a set of Sagas and a target release date.
      1. If date-driven, only the highest-priority Sagas would be selected.
      2. If feature-driven, the roughly-estimated release date would be calculated.
      3. Factor in non-feature work, such as fixing existing bugs.
2. Refine the plan
   1. Break down each Saga into Epics that can be more precisely (but still roughly) estimated.
      1. Each Epic should still be a high-level, user-facing, cross-functional feature.
      2. Epics should typically be what the team could accomplish in 1-3 sprints (or 1-6 weeks for Kanban).
   2. Estimate each Epic
      1. Best to involve the whole team, but an experienced Team Lead may suffice.
      2. Consider the effort that will be required by each function (e.g. coding, design, testing).
      3. Whenever possible, compare to other Epics, so estimates align.
      4. Think back to similar Epics in the past, and try to remember any surprises.
   3. Given velocity and estimates, project the scope and release date
3. Further refine the plan
   1. Break down each Epic into Stories.
      1. Each story can be within a single function (e.g. Design), as long as it is still an independent, user-facing feature.
      2. Whenever possible, look for low-priority stories to split out, and remove from this milestone.
      3. Try to specify remaining stories at an MVP level (no bells or whistles).
   2. Each story should be estimated by the entire team.
      1. Each story should be sized to be roughly 10-20% of the team's work in one sprint (or Kanban equivalent).
   3. Given velocity and estimates, project the scope and release date

Breaking down and tracking individual Epics

When an Epic is present in the backlog (through any of the above processes) and becomes the next most important thing to do, a contradiction arises: Epics are by definition too big to work on. There are several ways to break up Epics, depending on whether Epics are used as temporary placeholders for to-be-determined detailed Stories, or as permanent tracking entities.

Approach A: Explode Epics on contact

1. The first time an Epic is the next thing to do, break it into Stories and close the Epic.
2. TBD: When?
   1. Break out Epics during backlog grooming.
   2. Break out Epics during Planning.

Approach B: Shave Epics gradually.

In the Project Board, use a separate column for Epics.

1. In the triage meeting, when an Epic comes up for review:
   1. Option A.
      1. assign Epic to somebody
      2. Move the Epic from In Triage to the In Progress column
      3. When they start work on it (not during the triage meeting), the first thing they do is some work breakdown, defining a new, reasonably sized next task for it
         1. do this using the "subtask" shortcut, which has the effect of making a new task and marking it as blocking the Epic
         2. assignee then assigns the Epic back (to who?)
         3. start working on that task
   2. Option B.
      1. create a placeholder Story and assign it
      2. Leave the Epic in the Epic Column
   3. Option C.
      1. do enough work breakdown to define the next, reasonably sized story for the Epic
      2. Assign this story
      3. Leave the Epic in the Epic Column
2. At the next triage meeting, check the Epic. Does it have any open tasks?
   1. If so, no further action in this triage meeting.
   2. If not, is it Done?
      1. If so, close it and move on
      2. If not, do more work breakdown, using Option A, B, or C above.
      3. if it has no open tasks related to it, see if it's Done. if not, continue:

Good stories

A good Story in Scrum is small and meets the INVEST criteria.

(Can we agree on best practice for ideal story size? One expert suggested 10-20% of your velocity.)

Use the Story Splitting Flowchart to break large stories into a set of smaller stories.

See also 10 useful strategies for breaking down large User Stories

Prioritizing product backlogs

1. Cut early and often
   1. anything you can cut, you don't have to look at again, much less actually do
   2. Look to cut:
      1. anything that doesn't fulfill a high-level goal
      2. anything that doesn't have supporters/audience
2. In order of the higher-level goals
   1. within all tasks that fulfill a higher-level goal,
      1. End-to-End, Breadth before depth.
         1. prioritize stories that complete a full pass through the product before stories that add features to an existing part of the product flow.
      2. handle items with a high value-to-cost ratio sooner
      3. handle high value items sooner
      4. consider handling high risk items sooner
   2. how to handle conflicting higher-level goals?
3. Preserve capacity
   1. Things that are blocking lots of people
   2. things that affect productivity
      1. hitting WIP limiters
      2. impediments, tooling issues and other issues that affect velocity
4. Build capacity
   1. prioritize scaffolding, and stories that obviate scaffolding
   2. eliminate bottlenecks

See also

• Community Tech team/All Our Ideas/Process
• WMF product development process might be the project which this page is part of (someone please clarify)