(In this blog post we share the first two of the areas that we address in our new free ebook called Ultimate Agile Planning Handbook)
Timebox – Everything
Timeboxing refers to the act of putting strict time boundaries around an action or activity. For example, you may want to timebox a meeting to be 30 minutes long to help ensure that the meeting will begin and end on time with no exceptions. When you timebox an event the result is a natural tendency to focus on the most important “stuff” first. If you time box a meeting, you would expect then that the absolutely required content of the meeting be completed before the end of the meeting. Other meeting agenda items that are not as important may get moved to another meeting. In essence, timeboxing is a constraint used by teams to help focus on value.
One important timebox that Agile promotes is the project itself. Contrary to Agile mythology, Agile teams prefer to have a timeboxed project since it offers a fixed schedule and a fixed team size. With these project constraints the team can better work with customers to maintain a laser focus on value, which ensures the team is building and delivering the most valuable work as soon as possible—leaving the less critical tasks to the end. Timeboxed projects may mean that some requirements won’t get implemented. However, it will help to ensure that what is developed is truly the most essential of the required features.
Timeboxing also helps to prevent a common problem in software development called “feature creep,” where teams incrementally add features to software without scrutinizing relevance or need. Feature creep leads to wasted effort in both the development and maintenance of code and can significantly impact quality and timelines on a project. Timeboxed project teams work to minimize the effort and resources needed to achieve the expected value. Some refer to this as the minimum viable product or the minimum viable feature set. Timeboxing iterations places emphasis on ensuring that teams do not experience feature creep. See Figure 1.
Agile teams not only like to have timeboxed projects, they also prefer to break projects down into smaller timeboxed durations, commonly referred to as iterations. You may have heard of iterations by a different name if you are familiar with the Scrum agile methodology where they are referred to as Sprints. Iteration lengths are fixed and not flexible in anyway, meaning it will end regardless of whether all assigned work is completed. Outstanding work is either assigned to the next iteration, or reprioritized amongst the remaining tasks. The general rule is that iterations should not exceed 30 days in duration, although some teams use iterations that range from 4 weeks to a single day. The length of an iteration is largely determined by how a team and customer are required to work together.
Iterations are important to Agile teams as they represent the block of time during which they will produce the mostly finely delineated plan. Because the iteration is a shorter duration than the entire project, the team can finish an iteration plan in a few hours after which it can get deconstructed right down to the task level fairly accurately. At the beginning of an iteration, a team will work with the customer to select an appropriate amount of requirements to include, with the intent being that all chosen requirements will be completed within that iteration. The team will then work together to break-down the selected requirements into smaller pieces until the team is happy with the level of definition required to do the work. At the end of an iteration, the team releases some form of software for review by the customer or the customer advocate. For example, in the Scrum methodology, the Sprint culminates in a Sprint Review meeting with the customer to demonstrate the software and gather feedback about what was produced during that Sprint. If the team and customer want tighter feedback because requirements are rapidly emerging, then it’s a good idea to schedule shorter duration iterations.
Having iterations that are too long (many months, for example) require much more planning and have a higher risk of slippage and error. In addition, the feedback loop between the customer and team is much longer providing a greater opportunity for the team experience rework due to errors or omissions. However, having iterations that are too short can also cause problems. With every iteration comes some overhead — specifically iteration planning — reviews and retrospective meetings. In addition, short iterations leave teams struggling to produce something of value before time expires.
To find our more about agile planning to stay on top of your backlog and manage your iterations like an Agile guru, download our free ebook Ultimate Agile Planning Handbook. It addresses the areas of agile planning: