Compendium / Development Process / Artifacts
Overview
Much of the training and literature on iterative development process focuses on planning and tracking the schedulable work, but that is only part of the picture in a development cycle. Development Logs (DevLogs) are used to capture a more holistic view of iterative cycles in a uniform and lightweight manner across teams.
Outcomes
When DevLogs are used as intended, the following outcomes should be realized:
- A concise picture of the scheduled work, interrupt-driven work, and available capacity for the cycle are all available for the team and others to view.
- Team members spend less time providing ad hoc updates to interested parties by referencing the DevLog.
- Cycle Retrospectives have more continuity across cycles, nurturing critical thought around team effectiveness and helping team members realize the benefits of being engaged in the retrospective.
Assumptions
- The Team Steward assures that the DevLog is kept up-to-date on an ongoing basis throughout the cycle.
- Team member emergent, interrupt-driven work is captured in the Non-Backlog Items section on an ongoing basis.
- Information in the DevLog is used to provide context for understanding, not ammunition for accusation or ridicule.
Usage
The Development Log should be created either in advance of or immediately following Cycle Planning, so that it can be populated with the plan for the cycle and interested parties can be notified.
The DevLog should be updated at least daily with the current state of the Backlog Items and Non-Backlog Items sections. Updating it immediately following a Daily Standup is usually convenient, as team members have just apprised everyone of the state of what their current work.
The Retrospective Notes section is meant to serve both as a facilitation tool for dialog among the team during the retrospective and as a journal to keep a record of the outcome of the event. One healthy activity is to periodically review a collection of DevLogs and go through the Retrospective Notes in chronological order. The entries serve as a team diary of sorts, and can help a team see how they have improved over time, especially if the current period is exceptionally challenging or intense.
Similar Concepts
- Sprint Summary Document (Mike Cohn)
- Sprint Report (JIRA Agile)
Structure
There are five sections of the Development Log format. The purpose and form of those are outlined below. An example of a complete log can be seen in the DevLog Example.
Cycle Details
This initial section concisely captures top-level details. At a glance, readers will know the name of the cycle, start and end dates, the amount of schedulable work committed to the cycle, and (at the end of the cycle) the amount of schedulable work completed for the cycle.
The details section also shows what the team’s metrics were as they entered the cycle. Having both the Throughput and Committed-to-Completed Ratio captured here lets the reader know what guidance the team had from their metrics prior to forming the plan for this cycle.
Backlog Items
The schedulable items pulled from the Backlog into the cycle are captured here. Initially, it will contain the outcome of Cycle Planning, but as the cycle unfolds, schedulable work added to the cycle will also be reflected here.
Keeping the status of the items updated on a daily basis makes this artifact even more valuable, since dependent teams and stakeholders are often able to see what current progress looks like at a high level before deciding whether or not to go interrupt the team for an update on a specific item.
Non-Backlog Items
It’s important that the interrupt-driven work in a cycle be captured as well as the schedulable items. However, avoid going into too much detail on these. The idea here is to cultivate a general idea of how much interrupt-driven work affected the team in this cycle.
Over time, the team should develop a general idea of what I call their Ratio of Scheduled to Interrupt-Driven Work. This allows them to set expectations both for themselves and others that there will always be some amount of interrupt-driven work for the team, and scheduling as if it did not exist would be irresponsible and counter-productive.
Team Availability
When someone outside the team sees that a particular cycle’s completed work falls below that team’s throughput, there is a tendency to assume that something went wrong. Having a snapshot of what the team’s available capacity was for the cycle makes it easier to explain lower delivery levels to those lacking that context without the Team Steward having to talk each person through the explanation.
Retrospective Notes
Inspection and adaptation for how the team works together happens at the Cycle Retrospective. Without capturing a record of what is discussed, the insights that emerge, and suggested experiments for improvement, much of the retrospective’s value is forfeit.
Capturing retrospective notes in the DevLog during the session can also facilitate better discussion among the team. I am fond of entering the notes live and having another person project the saved notes on the room’s large display. This allows me to live edit on my laptop without the team having to watch me type, and periodically prompt the person to reload the page.
This also affords me a natural opportunity to confirm that both the team and I are hearing what we are saying to one another. Reviewing the notes, I’ll often say, “So what I heard you all saying was this.” If it is on-track, then they’ll confirm, but if not, it prompts clarifying dialog among the group. I have had this simple technique lead to the team understanding one another in areas where we had previously been talking past one another time and again.
In our example team’s retrospective notes, it seems like there was good discussion among the team that allowed meaningful reflection about the cycle to take place. Both the things that are working well and the things that could improve seem meaningful, and they took the next steps to identify experiments to address the things they would like to improve:
