Shape Up Forum

Github vs Basecamp board: What goes where?

Hi Ryan!

I’ll try to go straight to the point with an example.

We use both Github and BC at my company. We’ve adopted the pitch strategy where we work out an idea in private and when it’s ready we share it with the company. (17 people including founders, devs, designers, operations and sales).

The issue
I have a proposal for the dev team and it’s very techincal. Where does it go?

Lets say I want the team to spend some time working on our background jobs system.
The idea is: I want to prioritize certain jobs related to payments to prevent important jobs from getting stuck in a queue for a long time.

I found myself writing a github issue to outline what I wanted to accomplish and how to go about getting there. Then I thought this seemed more like a proposal (or pitch?) than an issue… Nevertheless, all the language is very technical. So where should that live? I’m not sure every issue in a webapp is a proposal… but they aren’t all bugs either.

Thanks for an awesome book and taking time with these questions!


Hey @gafemoyano - we worked through a similar challenge on our team recently and landed on the following principles:

  • Issues, feature-requests, and bugs get posted to Gihthub. These tickets just outline problems or ask for solutions that don’t require shaping. There can’t be any uphill questions left unanswered and the appetite for execution is measured in hours or days, not weeks.
  • Just about anything else would be considered a pitch and goes to the betting table.

If that doesn’t answer your question, I’d be happy to provide more color.

1 Like

Hi @mattdonovan, thanks for your answer.

That seems clear enough to me. In your personal experience, how would you handle kicking off the “tasks” assigned via issues en github vs cycle work? So far, I’m aware of two approaches:

  • Have a dedicated person doing support work during the cycle
  • Tackle it on cooldown

Thanks again for your answers!


Great question - there is another thread on just that. Here’s my answer:

1 Like

Hi Felipe

We also ran into a similar situation and, when the technical improvements take days, a pitch is also created. The pitch helps set the scope and appetite.

In our case, we have to have the CTO in the meeting so that the importance of the issue can be raised.

Business benefits (internal o customer-faced) can be explained in the pitch and that can confirm the value of the proposal.

This way, we can also make sure that we are not creating a pitch for just a new and hyped tech, like a new JS library or something fancy like that. We make sure to see the real business value.

In you case, sounds like internal efficiency, which is totally valid.


I highly-disagree with this approach:

Shape Up explicitly addresses the problem in the chapter: “What about bugs?” I suggest you re-read it now:

It sounds like you’re giving issues and bugs a license to bypass the normal scheduled work cycle. This is anathema to the whole spirit of Shape Up. It threatens to preempt your planning, cause confusion about priorities, and stress your team.

“There is nothing special about bugs that makes them automatically more important than everything else.”

Work on bugs during the cool down, send them to the betting table, or perhaps dedicate an occasional bug smash cycle of appropriate length.

What I’d suggest is to run Shape Up as you normally would in Basecamp (we prefer doing Shape Up in Monday), then simply allow your team to use Github to get the work done. In this way, Shape Up is how you define and decide what to work on and to discuss any concerns that come up, and Github is used to managed how the work gets done–the implementation details in terms of branches, commits and pull requests. We continue any discussion of the task in Monday (Basecamp for most of you). Github is just used to organize how features (as branches) and for versioning (commits/pull-requests). Sometimes the engineers discuss technical implementation details in Github, but discussion about the scope of the feature or business-rules happens outside of Github.

here’s some tasks in a teams current cycle in Monday, along with some discussion of a rabbithole that came up in the sidebar

These tasks get split up into multiple branches in Github–which business stakeholders don’t care so much about–and the conversion there is likewise technical (implementation details).

@maxhodges RE:

It sounds like you’re giving issues and bugs a license to bypass the normal scheduled work cycle. This is anathema to the whole spirit of Shape Up. It threatens to preempt your planning, cause confusion about priorities, and stress your team.

I suppose I could have called out explicitly that, while our team generally agrees with the spirit of Shape Up’s approach to bugs, we don’t feel great about any of the tactics. From my perspective, our team thinks bugs are different from other kinds of work in a few ways that make them worth triaging and prioritizing independently.

  1. A bug isn’t pitched, it’s reported. That means someone experienced it and it was bad enough for them to realize it. Bugs are embarrassing and, at least for now, our team is sensitive to that.
  2. Bugs often have few uphill questions. User-story-wise, we know what done looks like. We also have institutional knowledge about the development of that feature. Unlike shaping, the intended product is almost 100% prescriptive, which also makes them easier to size-up.
  3. Some bugs are leaches on previous bets. In Shape Up terms, if I make a bet on a pitch and the team produces something great that works, I’m making an assumption that it’s going to keep working. In that sense, I actually really like having ongoing bug fixes.

I should note that when any of our developers are working on bugs, they have had a hand in triaging them and deciding if what they’re looking at is worth working on right now or not.

I know there is some baked-in “stay busy” bias there, but our thought is as long as the engineer feels his or her time is well spent and they improve our product, what’s the harm?

1 Like

Our team here is very much in agreement with the Shape Up stance on the matter of bugs.

There is nothing special about bugs that makes them automatically more important than everything else. The mere fact that something is a bug does not give us an excuse to interrupt ourselves or other people. All software has bugs. The question is: how severe are they? If we’re in a real crisis—data is being lost, the app is grinding to a halt, or a huge swath of customers are seeing the wrong thing—then we’ll drop everything to fix it. But crises are rare . The vast majority of bugs can wait six weeks or longer, and many don’t even need to be fixed. If we tried to eliminate every bug, we’d never be done. You can’t ship anything new if you have to fix the whole world first.

Ultimately software engineering is about adding-value. Sometimes fixing a bug is the most valuable thing you could be doing. Often times it’s not at all. The resources dedicated to a bug fix should be weighed against all the other value-adding activities you could be doing.

You’ve already shortlisted your best value-adding raw ideas, you’ve shaped them up, brought them to the betting table, and the team voted to bring them to the next cycle. Now you’re going to pre-empt all that evaluating, prioritizing, and planning because someone noticed your software isn’t perfect?

Frequently it makes little sense to interrupt the team’s momentum toward their current tasks just because someone found a bug. Surely whatever the team is working on must be something deemed to add a lot of value otherwise it wouldn’t have gotten past the betting table. A new feature might add value to a great number of customers while the bug might only affect a handful of users and in only a small number of circumstances. These things really need to be considered in the context of their impact and all the other value-added things you could be working on. Otherwise, you might win the Battle of the Bugs but lose the war for profits and market share and cede your competition an opportunity to win the hearts and minds of your customers. Your “bug-free” software can’t keep up with the velocity in which my team is able to add game-changing features.

The embarrassment you speak of is something we explicitly embrace. I’d rather apologize to a minority of inconvenienced customers than lose valuable momentum on a high-impact feature that’s going to wow masses of users, significantly improve operational efficiency, accelerate our growth, and have a big positive impact on our bottom-line.

That being said, we do care about bugs and we have processes to deal with them, we just feel their priority should be determined by a rational evaluation that puts them in context with other value-adding activities.

Think in terms of grading bugs along a “Bug Bell-Curve.” A small percentage of bugs demand immediate attention, a small percentage can be ignored for years, and most fall somewhere in-between.

Cheers! :ant: :spider: :mosquito:

1 Like