If you had to use Jira, how would you set it up for ShapeUp? I realize this isn’t ideal, of course, but it’s pretty common for Jira to be the preferred project management tool for an entire organization, with individual teams unable to choose to use something else.
2 Likes
Disclaimer: I’m shooting from the hip here 
If you’re projects are set up using Jira next-gen I would:
- Disable backlogs
- Use confluence for pitches
- Use boards as the hill chart a column per position on the hill?
2 Likes
I tried setting up Jira for Shape Up. The one thing I could not manage to do is recreate the way we make to-do lists for the scopes in Basecamp and capture discovered tasks beneath them as we go.
1 Like
Thanks for the insight @jerrylopez!
Ryan, how did you map concepts between ShapeUp and Jira? Best I can come up with is:
Project <–> Jira Epic with link to Confluence page for pitch/kickoff, as @jerrylopez noted
Scopes <–> Jira Issues
Discovered tasks <–> Jira Subtasks within each Issue
Subtasks in Jira are obviously not as lightweight and easy to work with as to-dos in Basecamp (because it’s Jira, and none of it is lightweight and easy to work with, ugh), but this seems like it would work? Were you running into something else that made this unfeasible?
I remember feeling skeptical that Issues and Subtasks were lightweight enough to work for managing scopes — which are captured and changed as we learn, not planned up front. But please give it a shot and let us know how it goes.
We are just about to run our first cycle and have been running Jira for many years, so we’re basically stuck with it for now. Our plan is this:
- No backlog. The Jira project is cleared after each cycle.
- One batch = one issue with a squad assigned to that issue
- We will install a plugin called Issue Checklist Pro which adds a pretty light weight checklist to the issue where we can group items in scopes in a similar way as it’s shown in ShapeUp.
I’m happy to give you guys an update once we’ve gotten started.
We still have to figure out how to represent the Hillcharts in Jira. Initially we are just not going to use hillcharts. One idea that I’ve had is to say that one batch is one epic and that the scopes are issues (with the checklist plugin on them). This would not give a single overview over how the scopes are going as how many checklist items are left. But maybe that’s an irrelevant number to look at?
Using Confluence for pitches sounds smart. We are planning to try out Trello, but I’m afraid that Trello is simply too lightweight to present the pitches in a good way. Any one have any experience of that? (Sorry if that’s of topic)
1 Like
I think I have enough experience with both to recommend something here.
- Set up a scrum project. This is your “team”
- Make sure epics, stories, tasks, and subtasks are enabled
- Write pitches somewhere like confluence
- Set up columns on the board to represent the hillchart. Something like ready, figuring things out 1, figuring things out 2, ready to make it happen, making it happen 1, making it happen 2, done (sorry not feeling creative on names for those). The ready to make it happen column is important for teams that would prefer to get all scopes up the hill first by doing all the hard stuff.
- Epics are your projects. Create each epic at the beginning of the cycle that will be worked on. Close epics at the end of each cycle.
- The backlog is the unscoped work for the cycle, the team should put discovered tasks in the backlog during the cycle before scoping
- Stories are scopes. Assign the stories to an Epic and move them into the sprint. Convert tasks in the backlog to subtasks of the scope stories. Those can then be tracked on the hillchart board. Instead of moving sub tasks across the board, click the story (scope) and change it’s status accordingly. Sub tasks can move directly from ready to done as needed
4 Likes
This is what it looks like for us at the moment.
Epic is the cycle work. Right now I have it grouped by Epic with only 1 showing. Custom issue type of scope indicated in red. In this case, “Split public / private embed API” and “New pricing plan for basic.” Clicking “+ Create issue” adds a new scope.
Subtasks are discovered work:
Pitches, ideas, and collaboration happen in notion and elsewhere. It should only land in Jira when we’ve committed/bet on it.
2 Likes
Great suggestions everyone! Lots of options to try out here.
For what it’s worth, I just tried adding a subtask in Jira, and this thing wants me to fill out a 16 field form just to add a little subtask! Now I know what @rjs was talking about. That’s so much more involved than I remember.
2 Likes
Hey @kevinsmith here’s what it looks like for our setup.
https://www.loom.com/share/f5bed06cb014407e881b035fd6a97a54
It’s heavy handed for editing or deleting, but adding is fairly quick. Hope that helps.
Oh yeah, that’s a lot better. I wonder if that’s only available in “next-gen” Jira.
1 Like
Could be a configuration thing as well. Jira can be setup to become a nightmare of required fields and the likes.
2 Likes
I think it’s really nice. I’ve did a similar thing in Azure DevOps, since it was decided to use that instead of Basecamp for project management in dev.
Perhaps the last swim lane that is breaking it up at the task (or sub-task) level is taking it a bit too far? Since this is mirroring Hill Charts, it feels like the value is mostly at the Scope layer. Curious about how you’re also using Hill Chart stages at a higher Projects later. Keen to hear how that goes and if you found seeing where an entire project is helpful. And if this method allowed you to track that in a way that felt accurate.
Thanks for sharing! 
Thank you @Aylon. This is super rough and only conceptually at the moment (not implemented yet). Ideally, I want to not use Jira, but tech teams are concerned about using Basecamp to support things like:
- How can we track dependencies between tasks in each scope?
- How can we reference tasks to GitHub repo and do bi-directional linking?
- How can we track tickets in testing environments?
- How can we create release notes?
So, this is an attempt to make a small step toward some of the principles at the delivery level. Any suggestions on the approach are welcome. I think tracking projects is an interesting idea for sure though. I wonder if Basecamp should allow projects to be grouped so as to make it more applicable for larger companies.
Is we can ignore subtasks, that would be great. Will the data hierarchy of Jira allows for this? Be great since subtasks are a pain.
Those are similar questions to the ones I faced when trying to make a similar case. Sadly, I lost, so not sure I have much advice to help with this. Maybe @rjs can shed some light on how Basecamp approach it, since I believe they also use Github. You could try asking DHH on twitter. If you get any good answers, please share in this post, as I’d love to know, myself!
To my knowledge, large companies aren’t Basecamp’s primary market, so not sure if they would go that route. Not unless it made sense for smaller businesses or themselves, as well.
As for the data hierarchy, I think you should be fine. In Jira, you can treat the “Stories” as “Scopes” for the Hill Chart. All sub-tasks for the stories are the equivalent to the To Dos in Basecamp, which aren’t tracked in the Hill Chart anyway. It’s a fairly clean 1:1 Jira vs Basecamp comparison there 
The way we approached this aspect was that the Hill Chart is about transparency for the project, to both the team and those outside of it. Sub-tasks are far too granular to be useful for this. So they’re purely for individual team members (and their colleagues, if they need to collaborate) to keep track of their own work and everyone else can pretty much ignore them.
For sure. Yeah, we’re thinking about keeping Jira for tasks and having that integration continue with GitHub and simply have the product managers work with the delivery managers on the engineering side to use Basecamp for scope tracking only (no tasks in BC).
For me this mapping works best:
- Jira epic = a feature
- Jira story = a single user requirement
- Jira subtask = a technical to-do item
I also went one step further and built a Jira app (plugin) that combines the above into one view together with the hill chart. The idea is to stay on one page to do everything. Add a scope, check off to-do items, move to-do items, update the hill chart, etc.
Here’s the Jira app → Atlassian Marketplace
@ mhl66 Could you elaborate your needs for dependency tracking? When was the last time you wanted it? What where you trying to do in that instance?
2 Likes
We started with a Kanban Board for Epics with Columns:
- Start
- Uphill (unknown)
- Downhill (known)
- Finish
For the task management of ourselves, we just have the classic 3 columns Kanban Board, but had “swimlanes by epic” activated. So it is easier to change the epics of the tasks.