24 October 2016
Sitka specializes in software development and consulting for various environmental conservation and sustainability organizations. It has been using Mingle for 8+ years now. We interviewed managing partner and co-founder Matt Deniston and marketing manager Damon Knight to learn about how Sitka uses Mingle.
In the interview, Matt showed us how Sitka sets up Mingle Card Types, Mingle Trees to model their project, and how they use Mingle wiki pages in their day-to-day work.
A Mingle Card is a representation of any entity you want to manage and track in your project. You can design different card types based on your projects’ needs.
While interviewing Matt and Damon, I was very impressed to see how Sitka adapted their card types over time. As their teams became more and more mature in Agile development, they simplified their structure and settled on three core card types:
Deliverable is an item customers contract Sitka to provide, it’s used to track key outcomes and underlying stories that support it. This is an example deliverable card: “Summarize program accomplishments.”
A Sprint card is used for planning and tracking. A typical Sprint card has a title like this “Sprint 32 (10/31/2016)” to specify the sprint number, as well as sprint end date.
A Story card is used to represent any work, but Sitka makes sure the vast majority of Story cards are something the client could understand and would pay for. In the past, Sitka used more card types to represent their work: story, user task, bug, contract tasks, etc. But the time needed to maintain these many different card types ended up costing more than the value they were providing.
When asked about their thoughts on card type simplification, Matt said: “The differences (between story and tasks or bugs) are irrelevant. If it is something the team need to work on, we just make a story and work on it. By doing this, it makes our life simpler and also makes it easier for client to engage with it.”
Mingle’s Card Trees allow you to define a hierarchy of parent-child relationships between any card types. It is very useful for the team to model the work breakdown or their release iteration plans.
At Sitka, continuing with their mantra of “simplicity”, they settled on only two trees. Each tree only has two levels.
A Deliverable tree only has two card types: Deliverable and story. The “deliverable – story” relationship helps track all the stories under a contracted deliverable. Three aggregate properties are used on the deliverable cards. They are: total story numbers, story estimates and completed story points for each deliverable.
Sitka’s Sprint trees have only two card types: Sprint and Story. The “sprint – story” relationship helps teams with sprint planning as well as reporting against the sprint. There are also three “aggregate properties” on sprint cards. They are: total story numbers of the sprint, completed story points for the sprint, and remaining story points for the sprint.
Mingle pages are where anyone can add information on any topic relevant to a community. It also allows you to use Mingle Query Language to create customized reports on the page. Matt is a Mingle MQL pro, and he told us: “As product owner, it (deliverable card wiki page) gives me more ability to customize the presentation of the information than simply a list of cards.”
Here are some great examples showing how Sitka gets value from their wiki pages.
Along with these key documents, we also see the budget, project timeline, and a link to the contract. This gives the team quick access to all key project information in one place.
On Sitka’s Mingle wiki pages, I saw two types of charts used most frequently: deliverable status reports and sprint burnup charts. Deliverable charts give you an overview of the completion status of each deliverable. Sprint burnup charts track the progress of the current sprint.
One example of how Sitka uses table queries is showing all the newly added stories on the project overview page.
Have a simple table listing the contact info for everyone on the team, both internal and external. It includes a contact’s name, role, office number, cell phone number and email.
Sitka also uses their Mingle wiki to create a rolling list of team meetings, including the agenda, minutes and action items. Then everyone can search for, and access, that content inside Mingle if they need to.
After Matt walked us through all of Sitka’s Mingle project settings, I was super impressed by the simplicity of the template he and his teams have created and used. Even more impressively, they’ve pared down complicated settings, leaving only the essential stuff. I really liked what Matt said: “In the true agile team, we really try to keep things as simple and small as possible”.
“A lot of the flexibility Mingle offers allows us to be able to adapt the standard project management approach and what we track over time. We evolve and we have the good stuff built into our Mingle template."
Special thanks to Matt Deniston and Damon Knight.