How we use Story Workflows (née Teams) & Projects for the product management of Shortcut

Note: This is the second post in a series of four posts on how we use Shortcut for the Product Management of Shortcut. For other posts in the series check out the links at the end of the post!

Update: As of 7/23/19 we have updated Teams and replaced it with a more descriptive name: Story Workflow. While the name has been updated no functionality has changed. Learn more about this change in this blog post.

Now it’s time to look at how we use Story Workflows (formerly Teams) & Projects. In Shortcut (the product). A Story Workflow is a collection of related Projects with the same workflow. At Shortcut (the company), the relationship of the Projects could be based on role, purpose, department, or any number of other factors.

“Story Workflows” should:

• Have a clear purpose.
• A clear workflow that aligns with its purpose.
• An understood owner (either a group or individual).

Some of the ways we group projects into “Story Workflows":

• All Projects related to active development.
• All Projects related to active development for a specific squad.
• Backlog management.
• Team specific Projects (Marketing, CX, etc.) that aren’t part of another purpose (like active development).

Because of the way we use Story Workflows means that Projects can be used for any number of purposes, Projects do not have a specific definition. Their content and format depend on usage. However, we do have some considerations when creating and using Projects.

• Does the content of the Project match the purpose of the ‘team’?
• Is a label or epic more applicable?
• Does the Project have a clear purpose or goal?

Story Workflows & Projects in action at Shortcut

To illustrate this a little further, let’s look at two types of “Story Workflows” we use at Shortcut: one based on a department - in this case, Engineering - and one based on a purpose - in this case, Unsolved User Problems. Due to their different natures, each one has a specific workflow (which I’ll also detail).

Engineering as a Shortcut Team:

At Shortcut “Engineering” projects are where any given group (e.g., backend, frontend, DevOps, etc.) goes to see what work they have assigned to them, which is related to active development. “Active development” includes any story that has been prioritized either because its parent Epic is linked to a current Milestone or because the story was prioritized in a prioritization planning meeting.

Engineering Projects should:

• Have one project per group involved in active development, including non-engineering teams responsible for deliverables (like design, marketing).
• Organized in a way that can be used in daily/weekly standup/planning meetings.
• Include only work that has been prioritized.

Engineering Projects should not:

• Include work not related to active development.
• Include backlog work or other unprioritized work.

Projects within the Engineering Team look about how you’d expect. There’s the standard “group” stuff that you’d expect, i.e.:

• Backend
• Frontend
• DevOps

We also have additional projects for work done in support of Engineering stories, while not sitting within the Engineering “department” or team, i.e.:

• Design: work by the Design team in support of Engineering stories.
• Product: work by the Product team in support of Engineering stories.
• Analytics: analysis in support of Engineering stories. e.g., feature releases.
• CX: work by the CX team in support of engineering stories. e.g., feature releases.
• Marketing: marketing work in support of engineering stories, e.g., feature releases.

The Engineering Team’s workflow tracks the progress of work. The workflow looks like this:

Unstarted:

• Spec Needed
• Ready for Dev

Started:

• In Development
• Ready for Review
• Deployed to Staging/Canary
• Ready for Deploy

Done:

• Completed

Unsolved User Problems as a Shortcut Team:

The Unsolved User Problems ‘Team’ (UUP) is where all feature requests and known user problems are recorded and triaged. This is where all non-active development stories/ideas/requests are kept until they are moved into active development. All your personas can be accounted for in UUP including, your internal tech teams, APIs, internal stakeholders, etc.; they do not need to be limited to your end user personas.

UUP Projects should:

• Be specific enough that it’s clear where to put a request but not so specific that we have many overlapping projects
• Have a clear description
• Contain stories that are worded with a clear user problem rather than a specific solution to a user problem (possible solution ideas can be listed in the notes)

UUP Projects should not:

• Be feature specific

Here’s some examples of projects we have in our UUP team:

• Epics: Issues specific to Epic creation and management.
• Milestones: Issues specific to Milestone creation and management.
• Notifications (In-App & External): All triggered notifications.
• Integrations: Any 3rd party/external integration requests.
• Billing (User Facing): User-facing billing issues.

Unlike Engineering’s workflow, which tracks progress, the UUP workflow tracks the priority of work:

• For Discussion: New requests that haven’t yet been assigned a priority, or that a team member would like to open up again for discussion.
• Low Priority: Someday we may do these things, but they’re not a current priority.
• Medium Priority: Candidates for next sprint/quarter but not critical enough to interrupt current priorities/roadmap.
• High Priority: Highly critical and should be slotted into the current sprint/quarter as soon as reasonable.
• Won’t Do/Outside Strategy: Based on current vision and strategy, we’ll never work on this request.

Priority for stories is discussed and decided in a weekly prioritization meeting. After a UUP Story has been prioritized, and work begins on it, it will get moved out of the UUP Team and into the relevant Project within the Engineering Team, converted into an Epic if necessary.

“Back-office” teams

But what about work that isn’t related to the product itself, i.e. “back-office” stuff like brand marketing, recruiting and customer support? We account for these as separate Story Workflows, e.g. Marketing, People & Recruiting, CX, etc. As mentioned, due to its sensitive and confidential nature, Finance has a separate, private Workspace.

To illustrate, here’s how some Story Workflows look in Shortcut:

Next up, we’re going to look at how we use Milestones & Epics at Shortcut.

How do you use Story Workflows & Projects at your company? We’d love to hear about it on Twitter.

How we use Shortcut for the product management of Shortcut series:

1. Intro and how we use Organizations & Workspaces
2. How we use Story Workflows & Projects (this post)
3. How we use Milestones & Epics
4. How we use Labels and how it all fits together