This writing piece will describe and summarise 'the betting' element of the Shape Up process, as a continuation to Week 2's instruction. The betting stage is cleverly parallelized to gambling environments in Chapters 7-9 of 'Shape Up - Stop Running in Circles and Ship Work that Matters, where key personnel come together to evaluate and select the best plan of action for the preceding cycle.

Shape-up uses the ‘betting’ term instead of the planning stage used by other methodologies as it provokes a different set of expectations throughout the team. In the gambling world, bets result in payouts, profitable compensation and/or growth. Bets are essentially reward-driven, whereas planning is seen as a time-box filled with tasks. Rather, a team will bet and commit to pursuing the goal, which encourages teams to take greater ownership of their projects. Furthermore, bets have a cap, which eliminates the possibility of runaway projects.

At the start of the betting steps, readers learn the importance of backlog, a term for a (typically rising) pile of delayed tasks. Backlogs can be seen as tardiness by a team, which is not necessarily the case. Not only that, but backlogs can squander valuable effort time while also limiting progress flow. Afterwards, the book illustrates brief, infrequent, and 1-2-hour meetings that mimic a betting table where stakeholders decide what to do in the next iteration. For instance, Basecamp's betting table consists of the CEO, CTO, senior programmer, and a product strategist and converse and question different perspectives on the numerous pitches presented. At the betting table, questions such as 'Is the appetite valid?' and 'Is this the right time?' should be posed. Typically only archived pitches are looked at in the meetings, and decide whether or not to gamble on the pitch. Meanwhile, other team members should track pitches, bugs, and requests freely. This approach spreads out responsibility candidly among departments and individuals to examine what is essential to them and focus on it with suitable efforts.

In the preparation for subsequent shape-up cycles, there are important components that must be clarified. The calculated length of the cycle’s efforts should last approximately six weeks, during which the team members should be able to see the end. In a lengthy cycle, the author suggests people can become complacent and procrastinate until the deadline approaches. As a result, six weeks is considered long enough to finish a significant feature while being condensed enough to forecast progress. After each six-week cycle, two weeks are set aside to cool down. Cool-down helps team members to allocate effort to resolving bugs and exploring new ideas. For solving bugs, the book recommends categorizing them according to their severity and likelihood of completion. If a bug is too grand to be fixed during cool-down, it can be prepared for future cycle proposals.

During cycles, the team is either improving an existing product or constructing a new one. Existing products should go through the same ‘Shape Up’ procedures, whereas new products are different. New product shape-up cycles can be divided into smaller iterative phases to help consistently mould the product as expected.