Why a Four-Week Work Cycle is Perfect for Complex Product Releases

\ One of the cornerstone decisions in product development is establishing the ideal work cycle. Modern software development often prefers agile methodology as one of the easiest and most effective ways to release. Waterfall can work too, but you should know why you are using it. Otherwise, iterations are generally a better choice. Everyone is used to them, and they are a failsafe strategy to develop great things. But what about the perfect length of an iteration?

\ The options depend on your company's product and deployment method. Is it a big monolithic system, or is it built on microservices? Does your product operate as SaaS, or is it on-premises software? Depending on the business positioning, you could choose between one- to four-week iterations. While one-week iterations are a widely known approach, in this article, I would like to discuss why a four-week iteration is great for big and complex systems and what steps this cycle includes

To find the perfect lifecycle, it’s necessary to understand the product you are working on. Let’s describe an example of a product that works well with a four-week iteration:

\

• B2B-oriented product.

  In this case, quality, stability, and predictability of releases are more important than quick delivery times.

\

• Product-oriented development.

  We are creating a product for the market, not custom software tailored to the needs of a single customer.

\

• On-premise deployment.

  The product could be SaaS as well, but when we’re talking about software that must be installed in closed corporate environments (like BPM, ERP, or EDMS), quick delivery times aren’t necessary and may even cause issues. These products cannot be updated the day after release, and iterations shorter than four weeks can create gaps between released and installed versions. This can lead to additional difficulties with customer issues, as tech support and QA engineers need to investigate the behaviour of older versions of the software.

  \

• Complicated structure or monolithic infrastructure with rich business functionality.

  If your product has a lot of features and complex interdependencies, it’s difficult to develop even MVP features without impacting the overall quality of the product. Shorter iteration times can lead to extended work on feature branches and tough merges, where delivering useful parts of a feature with every release becomes challenging.

\ In short, a four-week work cycle is useful for products where meaningful updates, product stability, and well-planned releases are more important than speed. Of course, there are some downsides, such as longer hypothesis validation times. However, for this class of products, immediate feedback is uncommon regardless of the iteration length.

\ \ Let’s break this process down across different teams of specialists:

\

• Product: UX/UI designers and system analysts.
• Development Team: Backend, frontend, and mobile developers.
• QA Engineers: Specialists who create test cases, develop automated tests, and perform manual testing.
• DevOps: The support team responsible for ensuring everything works seamlessly and deployment is possible.

Although this article focuses on a four-week iteration, the real work in this process begins earlier. The first step is to determine what we want to accomplish during the iteration. Business analysts, UX/UI designers, and system analysts must prepare and validate product changes, create mockups and designs, and develop detailed technical specifications for implementing these changes. I refer to this phase as the "N-1 Stage", where N represents the planned iteration.

\n It’s not necessary for all technical specifications to be fully prepared during the N-1 or N-2 stage. What’s most important is that during the N-1 stage, these changes are approved by the product owner and proceed to the grooming process.

\ During the grooming process, the entire team must fully understand the idea behind the feature or change and prepare estimations. It doesn’t matter whether you calculate estimations using T-shirt sizes, hours, or any other measurement technique. What’s essential is having clarity on whether the feature can be delivered in the next iteration (“N”) or if it needs to be broken down into a few minimally valuable changes. If so, the specifications can be revised and groomed again until the team is confident they can create a functional and meaningful release.

\ Later in the N-1 stage, we need to prepare the iteration planning. During this step, we aim to determine the most effective combination of groomed features for the release, based on team capacity, potential risks, vacations, and other obstacles. Each change must have a defined priority to identify what must be implemented and what can be postponed to the next iteration. For this, it’s useful to apply Dai Clegg’s “MoSCoW” method or the principles outlined in RFC 2119, as they follow a similar approach. Here, I will use “ / ” to separate terms from MoSCoW and RFC 2119:

\ 1 priority - Must have / MUST: Mandatory requirements that must be included in the product.

2 priority - Should have / MUST NOT: Important changes that can be postponed but would make the release less meaningful if excluded.

3 priority - Could have / SHOULD: Non-essential changes that would be nice to include if the first and second priorities are implemented without risks.

4 priority - Won’t have / SHOULD NOT: Less critical changes that are not intended for the current release but may be crucial for the next iteration. For example, these could be part of a complex new feature requiring extensive investigation or too large to be decomposed into smaller parts that can be completed in a single iteration.

\

:::info References:

Clegg, D. (1994). Case Method Fast-Track: A RAD Approach. Addison-Wesley

Bradner, S. (1997). Key words for use in RFCs to Indicate Requirement Levels (RFC 2119). Internet Engineering Task Force. Available at: https://www.rfc-editor.org/rfc/rfc2119.

:::

As a result, we have artefacts to work on, know the estimations for these changes, and are prepared for a brand-new iteration.

This is the stage where the main magic happens. It’s the longest stage of the iteration, lasting 10 workdays.

The stage should include the following activities:

\ For Everyone:

• Planning meeting: Held on the first day to refresh the team’s understanding of the iteration backlog, including the most important changes, priorities, and potential challenges during the iteration. It’s ideal to start a new iteration on a Wednesday.
• Grooming meetings: Preparing for the next iteration.

\ For the Development Team:

Implementing planned technical debt activities, vulnerability fixes, feature development, and any planned production bugs. It’s crucial that all significant changes (features, complex issues, or dangerous bug fixes) are handled in feature branches to avoid destabilising the general release. Work should be done in order of priority. By the end of this stage, developers should provide a demonstration to the product team and QA engineers responsible for the changes to check completeness and overall quality.

\ For DevOps:

• This stage is an opportunity to improve product pipelines or infrastructure.
• Support the development team by ensuring all necessary stages are in place for testing new changes from feature branches.

\ For QA Engineers:

• Prepare test designs or create new automated testing scenarios, working according to priorities.
• Once test designs are complete and the development team has finished "must-have" changes in feature branches, QA should begin testing these changes before the stabilisation stage.

\ For the Product Team:

• Prepare technical specifications and hold grooming meetings for the next iteration.
• Support the development process by providing additional clarifications about current changes. If necessary, update technical specifications or UX/UI designs to include new cases discovered during the implementation stage.

\ As a result of the implementation stage, we should determine what our release will contain and evaluate its overall quality. This includes deciding which features will be merged and which changes will be rescheduled to the next iteration with some improvements. Additionally, it’s a good idea to dedicate an hour of team time for a retrospective meeting during the first or second day of the stage. This provides an opportunity to review the results of the previous iteration and identify ways to avoid repeating past mistakes.

This stage lasts five days and focuses on stabilisation. During this stage, QA engineers should validate all feature branches and merge all changes into a single release branch. The stage should include the following activities:

\ For QA:

• Testing changes based on priorities and the test scenarios built during the Implementation stage.
• Logging product bugs.
• Validating fixed bugs.
• Approving fixed features for merging into the release branch.
• Performing a high-level check to ensure the feature works correctly after merging into the release branch.

\ For the Development Team:

• Fixing bugs according to feature priority as quickly as possible.
• Merging features into the release branch.

\ For the Product Team:

• Prioritising product bugs to determine the scope of the feature. Ideally, all features should be released as zero-bug features from the start. However, when compromises are necessary, you could establish a rule: all product bugs with priority 1 and 2 must be fixed in the feature branch, while priority 3 and 4 bugs can be addressed later in the release branch or postponed to the next release.
• Assisting QA and development teams in fixing bugs quickly and updating product documentation if any tricky edge cases are discovered during bug discussions.
• Preparing product documentation.
• Approving fixed features for merging into the release branch.

\ As a result of the stabilisation stage, you should have a release branch containing all planned features and only minor bugs.

The final stage leads directly to release. At this stage, the release scope is already defined, and every planned feature should be merged into the main branch. It’s crucial to stabilise the release overall and carry out release activities. The stage begins with creating a release candidate branch for final changes. The stage should include the following activities:

\ For DevOps:

• Switch the main development branch to the release candidate (RC) branch. All out-of-scope activities should continue on the main branch without interfering with the RC branch or introducing undocumented changes.
• Deploy the RC branch to test environments for release candidate testing.
• Assist with product release pipelines after testing is complete.
• Perform a security check and release a report detailing any vulnerabilities found.

\ For QA:

• Conduct release testing for the entire product, focusing on the changes made.
• Log product bugs that appear after merging all feature branches.
• Validate the product bugs.
• Generate reports on test coverage and test results.

\ For Development:

• Fix product bugs identified during testing.
• If time allows, begin working on tasks related to technical debt, vulnerability fixes, or features approved for the next iteration.

\ For the Product Team:

• Prioritise identified product bugs and decide whether they should be fixed in the RC branch or postponed to the next release.
• Finalise product documentation.
• Deliver a public product demonstration.
• Prepare content for app marketplaces, if applicable.
• Plan the next iterations based on estimates from grooming meetings.
• Make the final release decision based on QA reports.

\ As a result, the software should be released, and the process repeated.

\

The process can be adjusted to suit the specifics of your product but serves as a solid foundation. It’s crucial to document and share it with the entire team.

\ Consistency is key to avoiding rescheduling and irregular iteration periods. If a previous release was delayed and required five weeks to complete, you should not shorten the next release to a three-week iteration. Instead, adjust your annual release plan to maintain consistent four-week iterations. Otherwise, you risk creating another failed iteration.

\ After a few iterations, the team will adapt to this cycle, and members will instinctively know each stage and its deadlines. However, it’s still helpful to remind everyone of the current stage during daily status updates. For example:

\

• Next Wednesday, we will freeze the Implementation stage and begin Stabilisation. If there are any issues with closing tasks, please inform us beforehand.
• We are switching to the Regress stage. Please ensure everything is merged and ready for the release branch.

\ This work cycle helps to develop predictable releases and establish clear deadlines. It is particularly useful for small teams, planned client commitments, and, most importantly, manual testing. It also simplifies high-level negotiations with customers. For example, you can explain that an iteration takes about one month, with an additional iteration needed to account for potential risks when planning delivery timelines.

\ However, this cycle does have limitations, especially when market reactions and development speed are critical. If your backlogs are constantly shifting or time-to-market takes priority over overall quality, a different approach may be better suited.

\ In the end, you must choose a release cycle that aligns with your team and project needs. Many products may find a four-week cycle too rigid, making it an obstacle for market responsiveness. Simpler products or those in their sunset or support stages, where changes are minimal, may benefit more from one- or two-week iterations. It’s an important decision that the team should adopt wisely.