How to build a social contract for your agile team

Team charters, team principles or vision statements are nothing new. If you visit enough work places you might see old A3 posters printed out with some clipart and an acrostic poem spelling out R.E.S.P.E.C.T. These type of statements have a purpose – usually in the early days to support a new team – but without any updates they don’t mean much.

The purpose of a social contract is to document how a team wants to work together. It should balance inspirational statements with the details of actual behaviours and attitudes that the team want to see. A key advantage in having a social contract is that by defining what the team should look like, the team will start to consciously and unconsciously exhibit those behaviorrs and attitudes. Read more

How to visualize your Jira backlog using Tableau

To a person with a hammer, every problem is a nail…

Right now I’m going through a phase where my hammer is Tableau and everything can be fixed through a decent dashboard. To that end, I developed a dashboard that visualizes my team’s backlog of work.

My team isn’t strictly in ‘software development’ but we’ve come to use Agile as the foundation to managing our projects. It’s flexibility allows us to manage all different types of work (i.e. scheduled reports, analytical projects, user support, etc) using Atlassian’s Jira (with their Agile, Greenhooper, Zephyr plugins).

The challenge I’ve faced is that, as we operate in a shared service model, we have lots of competing requests from our customers. The challenge is balancing these requests at our monthly prioritization meetings. As pseudo-product owners these customers determine what we do but with so many competing agendas, how do we get consensus for where we’ll focus our effort?

Enter the prioritization dashboard.

The purpose of the dashboard is to answer the main questions our customers ask:

  1. What are my requests?
  2. How important are my requests compared to everyone else’s?

Generally, if these questions can be answered quickly and transparently (that is, each customer can see everyone’ else requests) it becomes very apparent which requests should be done before others. For example, should we prioritize the complicated enhancement for a report going to 5 people or a simple bug fix going to 5,000?

What does the dashboard include?

As you can see from the dashboard (nick named the petri dish), you can quickly get a sense where the more important requests are (top right hand corner). Using the filters on the right you can click on your team name (‘Learning’ for example) and have those requests highlighted on the matrix and the request details are listed below in the table. You can also get a feel for the size of the task and the nature of the request.

The following are the definitions for the custom fields used.

Components: the nature and type of request

  • Group initiatives are requests from senior executive stakeholders
  • Customer initiatives are requests from our stakeholders
  • Continuous improvement are requests from the team
  • Scheduled reports are reports that recur regularly
  • Fast track are requests prioritized for immediate delivery

T Shirt Size: An approximate estimate of effort based on initial assessment of a request before elaboration.

  • XS =< 1 day
  • S = 2 day
  • M = 5 day
  • L =10 day
  • XL => 10 day

Benefits Score: This is a measure of benefit value between 1-5. Benefits that may be identified include reduced costs, reduced risks, or improved employee value proposition.

Strategy Score: This is a measure of  strategic alignment between 1-5. A strategically aligned item should align to the strategic technology stack and be in alignment with the team’s development road map

Why build a dashboard when you could use Jira’s Agile plan view?

Despite Jira’s useful reporting functionality, it’s hard to intuitively represent to our less Jira-savvy customers what exactly is going on with our backlog. While a list is great when you going through iteration planning there isn’t enough information available without constantly drilling down into each issue. It’s also not clear which requests came from which customers. Plus, you know, the whole hammer thing…

How does it update?

The dashboard is delivered through Tableau. Currently, to get the latest request information, I extract it from Jira manually as a CSV and update the dashboard. This is fine as the dashboard only needs to be updated monthly and only takes a few minutes. That said, if you wanted ‘live’ data, Jira does have a restful API that you can plug into.

What’s next?

In true Agile fashion, the dashboard has some enhancements waiting in the backlog. The most important is maturing from using the benefits score and t-shirt size to using actual cost/benefit measured in dollars. Even though the team doesn’t currently have a charge back model, speaking in ‘dollars’ is something all customers understand. It also can tell a compelling story (for example, your enhancement will cost $10,000 of the team’s available effort – is that a wise investment compared to the benefits you expect?)


I’ve added a version of the dashboard with mocked up data to Tableau here.