Shape Up Forum

Hot to properly split cycles, projects and scopes

Hi everyone! Just discovered this forum and it couldn’t have happened at a better time.
I’ve read Shape Up in the past but didn’t have the opportunity to put it into practice (I’m going to read it a second time soon)…

I’m currently working as a tech lead for a small company in Brazil and was just recently given the opportunity to adopt a new strategy for my team. The team is composed of 4 senior developers (including me) and we have been working in (loose) cycles of 4 weeks for the past 2 years using Gitlab’s boards to do a little bit of Kanban (backlog → to-do → doing → done).

Since this is a greenfield project, we had a lot of “flexibility” around scoping our work - not without major challenges though, like dealing with stakeholder’s and client’s volatility and expectations.

This is a reality that probably won’t change because of the company’s culture and background. However, the technical team did and still does its best to remain detached from this reality. I’m comfortable saying that we feel like we work almost as a separate entity within our current company that has its own culture and processes, trying to deliver as much value as we can - given our constraints, of course.

So, after this introduction, I’d like to ask for some advice about some points I’m still unsure regarding implementing Shape Up at work…

What we are doing today

  • I started our first cycle with shaped work and it’s going very well so far (the amount of visibility the team has gained is noticeable from my end). By shaped work, I don’t mean work that is just well specified but also structured in the sense that we can now remove most of our unknowns and still give the team flexibility enough to come up with the implementation by themselves.

  • We are using Gitlab’s Milestones for cycles (deliverables) and we have a board for planning where I shape the work we are going to deliver (since I’m the oldest employee in the company and also the one that has the most history with the product) and development, where the team and I push the work forward to completion.

  • We have issues (features) that have a pre-defined budget of up to 4 weeks that we have shaped, pitched, and bet on before committing to work on it.

  • Each issue has tasks that the team ads while they are working on the discovery phase (to-do → discovery → doing → done); it’s not perfect but we are trying our best to adapt the process¹.

¹I’m still trying to convince our CEO to buy a license of Basemcap so we can improve our cross-team communication and gain visibility on our processes, but the currency rate exchange makes this decision a little bit harder than it should be.

The things that are not completely clear to me yet

  • It seems to me that when a new cycle is announced, I would have to create Basecamp Projects for each cycle project that I have. The problem is that because we are a small team, this means I’d have one person per project most of the time - which kinda defeats the purpose of having a shared space to work (in my mind at least).

  • It also seems to me (looking at the book examples), that I would define each project in the cycle in terms of a single feature, while the scopes (to-dos) represent the feature’s “requirements”. However, in our current scenario, we have very small features that don’t make sense to bet even 1 week of work on but are still important enough to be tracked. Those features usually compose most of our work routine… This means that someone will usually work on something and be ready to deliver another piece of shaped work. It seems to me that creating Basecamp Projects for this kinda work is a bit too much, but I don’t have another alternative yet.

  • Another thing that happens very often is that we have to release software mid-cycle. This of course, only makes sense for work that is already done, so we should be capable of delivering value as soon as possible if a client emergency comes up (and I’m not talking about just bugs here).

  • Right now I’m adapting our Gitlab board to adjust the team’s capacity inside our 4-week cycle. So no one takes two features (projects) that we bet 2 weeks on each or one project that we bet 4 weeks on. I also watched Adam Wathan’s talk with Ryan Singer (@rjs) in the past and they talk about scoping work inside a “box” to have a kind of self-organizing and controlled chaos. But I’m not sure I’m tackling this properly for our use case.

I’m doing my best to adopt as many elements from Shape Up that I can and I know we are already getting some benefits from it. I also believe that we have a long road to maturity as a team and I’d very much appreciate critics and suggestions to level up our team’s planning skills.


Three options to consider:

a) Save this smaller work for the cool-down period between cycles
b) Bundle these small tasks into a “small batch” project and set an appetite to it
c) Take the smaller work out of cycle and dedicate someone to tackle this list Kanban style

I think Shape Up is compatible with mid-cycle releases, although it is not best practice. I think the trade off is that it breaks the “uninterrupted time” principle of Shape Up. One of the first things I did when I started Shape Up (in addition to killing all the Agile meetings) was to enforce a release cadence, e.g. only one mid-cycle release per six-week cycle, and only on Tuesdays (so the devs could predict when their time would be taken from them). So while I couldn’t get rid of mid-cycle releases, I could make them less frequent and more predictable.

Best of luck trying to implement Shape Up!

Hi @nt-from-chicago, thanks for your time!

I was about to post when the forum went offline and had to wait until now to respond to your comment :sweat_smile:. Even though some perceptions have changed, I’ll post my initial comment with a small update at the end for context’s sake.

Because of low team capacity, I think option c) is out of the question. It also does not solve the problem we have today with process transparency, since Kanban’s “definition of done” gives little to no information about the actual work - it only deals in absolutes (done/not done).

Option a) seems the de-facto answer to this kinda problem, but since most of our work is composed of those “small projects”, I think all of our cycles would turn into a big ‘cool-down’ period :sweat_smile:.

Option b) seems very reasonable and I can see how this would work in practice, except it doesn’t answer my biggest question directly: For example, how do you set up this within a cycle (see my previous remarks)?

I do believe that’s the case and I agree it’s not the best practice, but it’s a compromise on my end to stimulate our environment to change. I figure that once this process is well established, we’ll gain a little thrust to improve our async work skills in the future.

Update 28/08/2021:

Since the last time we interacted, I ran two cycles end-to-end with my team and this helped me to test some theories in practice. I’d like to share my experience so far:

  • I tried bundling two to three tasks inside a “support” project within the Cycle but it gets very confusing to track scopes on the TODO tool with the current version of Basecamp (It seems that Basecamp 4 will solve this by allowing more tools per project though).

  • With only three developers now, everyone is doing a little bit of everything. Even though I’m still doing most of the planning and shaping myself, the team agreed that at our size, everyone is responsible to push forward the projects we bet on.

  • Each project we bet on has one person responsible for orchestrating the delivery. This means that we can scope three projects per Cycle and each “project lead” can coordinate with the other two developers if necessary. On this part, Basecamp has helped us by creating a framework that allows us to share information and have better communication.

Another thing that I’m going to try next is to go a little bit more “free-form” with some of the “small batch” stuff. We currently have a list of “quick improvements” that we are tracking. This list is composed mainly of tasks that don’t have enough input to become projects (bugs, small technical improvements, and R&D stuff). For us, these tasks are nice-to-haves, but it doesn’t make sense to have a project with a fixed scope and deadline attached to it (most of the time at least).

We have to be careful though as we might have other priorities for the Cycle, since those tasks can potentially consume more time than we want to spend at a given moment, the team is completely responsible for tracking the “scope” for those tasks and choosing if they’ll tackle it at the begging of the Cycle or at the end - usually projects will have priority. I can see creating a Cycle in the future with the same proposal as a “Bug Smash Cycle”, but for R&D work.