The Commitment Model of Work

This post is about a model for organizing the work of a software development team in Jira and for articulating why we work on the tasks that we work on. At the moment, I think splitting work into things that meet one of our agreed-upon commitments and things that don't have to do with meeting one of our commitments is a helpful model for categorizing work.

What is a commitment?

To start, a commitment is something we as a team have agreed to do or to provide either to ourselves or to someone else. A commitment can be formalized in a written agreement, or it can be an organizational expectation to provide some service or resource. The important thing is that our team has agreed to deliver something, usually over a set period of time, and there is mutual understanding and shared expectations between all parties to the commitment.

The commitment model uses commitments to judge what is important

Under the commitment model of work, the work that is most important (that is, worthy of the team's time, effort, attention, etc.) is work that supports, enables, or delivers on a commitment the team has made. If work is not related to any existing commitment the team has made, the work should be less of an immediate priority.

This is the commitment model of work. When presented with a question of whether or not you should do a particular task or request, ask yourself if doing the task moves you towards fulfilling one or more of your commitments.

If the work under consideration is not related to one of your commitments, you should examine the request very closely to determine the best course of action. Should the work under consideration become part of a new commitment? Does the work under consideration fit in with an existing commitment? Is there enough value for completing this work? Is it a recurring, long-term, or one-off work?

If you do agree to take on new work that is not part of an existing commitment, you should recognize that you have made an additional commitment. That new work is now a new commitment and should be treated the same as your other commitments.

This is only a guideline

This model is meant to be a guideline and not an unbreakable rule. If you believe that something is important for you to do even though it does not fit in with one of your existing commitments, you can do that. This model is meant to help in your decisionmaking for what gets your attention and what gets represented in Jira or other representations of work.

The Jira representation of the commitment model

At the moment, I think the way to represent this model in Jira is to have an Epic for every single one of your commitments. This means you would have an Epic for all of your roadmap/project items, and you would have an Epic for all of your regular work, like providing customer support, performing on-going operations, maintenance, and team organization work. The Epic should either contain or refer to definitions of your commitment that you have mutually agreed upon with all parties to the commitment.

Attached to each Epic are one more Stories that correspond to major areas of work, specific outcomes, or some identified value that you can provide as part of the commitment. The Story should at a minimum try to describe the current situation, what we think needs to change, and what we expect the resulting outcome to be. I think here it is important to not get too bogged down in the format or trying to fit a schema like "As a somebody, I want to do something for some reason". It's more important that someone who looks at the Story can understand what it is your doing and why at a reasonably detailed level instead of fitting somebody's idea of a standard format.

Finally, the actual work you plan to do goes into subtasks underneath the Story to which the work is related. In general, most of the work you do should be represented in Jira as a subtask attached to a larger Story aimed at delivering a specific outcome or value.

You can absolutely still use standalone tasks in Jira, but they probably should be for one-off occurrences of work. You could also start off work as a standalone task and the convert it to a subtask if it becomes relevant to a Story. You may also need to consider making a new Story based off the standalone task or a new Epic if the standalone task evolves into or reveals a new commitment for you and your team.

Why is a model of work useful?

A model of how you represent your work provides a philosophical foundation and a guide for deciding how to spend your time and effort. You likely have a model of work whether you realize it not. In many cases, in my experience, work in software development or technical fields is divided into "technical" and "non-technical" work, and "technical" work is often prioritized as more valuable by default. This unfortunately means vital work that keeps teams healthier and makes them more successful over the long run does not get the attention and care it needs because in this model of work you prioritize "technical" tasks over "non-technical" tasks. I believe if you held a different model of work you would behave differently.

I think the commitment model I have been exploring is a model of work that should allow me and my team to prioritize and balance our work more effectively and evenly across all of the activities we do as our regular work.