Agile project scheduling might sound contradictory at first. How exactly can you create or manage a schedule for a project with a scope that is evolves and changes frequently throughout development?
The short answer is you can’t. The more defined a project schedule is the less Agile a project will be.
This doesn’t mean Agile projects don’t involve any kind of project schedule management or that Agile frameworks can’t work well for projects with semi-fixed time constraints [1].
Realistically, the vast majority of projects have at the very least a general estimated end date and a finite amount of leniency for missing that end date so there must be some way to. Agile frameworks can’t be molded to fit any type of project but they can be implemented in ways that are more “time conscious” and result in a more well-defined project schedule [6].
In this post I will cover some of the ways Agile frameworks help to effectively manage time constraints. The methods covered in this post are all commonly implemented in many Agile frameworks and can be tailored to be more or less “time conscious” based on how you choose to implement them in a given methodology.
Relative Sizing and Timeboxing for More Accurate Schedule Estimations
Agile projects don’t engage in extensive initial project planning, instead only doing high level initial planning and more detailed lower-level planning when it’s time to work on implementing a certain feature.
More detailed lower-level planning is done incrementally throughout the project as it is needed to implement features. This naturally leads to a limited level of schedule management on a project wide scale and a relatively high level of schedule management of individual project sections [6].
This allows for a high level of flexibility but the lack of concrete reference points can make estimating project duration or telling how the actual progress is comparing to the expected project progress very difficult. Agile does have ways to mitigate this while still maintaining Agile’s core flexibility; relative sizing and timeboxing are two such methods [2].
Sizing
Sizing in Agile refers to estimating the time and work involved in implementing a particular feature in relation to the product’s other features.
Estimation isn’t something human beings are particularly gifted at to begin with but the accuracy of our estimations. Add to that the fact it is also highly dependent on how much previous knowledge and experience we have of similar things and you have a recipe for a highly unpredictable level of accuracy [3].
You can probably see why at the start of an Agile project, when features are only defined at a high level where more is unknown than known, estimation can be particularly tricky.
An important aspect of relative sizing is that it does not just take into account the work involved implementing a feature but also take uncertainty into consideration. This can be seen in the table below that uses a common method involving the Fibonacci sequence to define a relative sizing scale [3].
Now you may be thinking, great now I have an estimate of relatively how much time features will take to implement but happens when one of those estimations is wrong or something unexpected happens and a feature ends up taking much longer than expected?
This is where a common part of many Agile frameworks called timeboxing can be beneficial.
Feature Timeboxing
The Agile Alliance defines timeboxing as “a previously agreed period of time during which a person or a team works steadily towards the completion of some goal” with the restriction that work will stop at the end of the timebox regardless of whether or not the task is complete [4].
For this post I am specifically referring to the way many Agile frameworks implement timeboxing to set a standardized amount of time to work on one or more features often referred to as Sprints or Iterations.
Timeboxing can be done at a very high level for an entire project to give a rough estimate of the project’s total duration by using the duration and number of sprints. This can help product owners conceptualize how long features take to implement and set their expectations as to what can realistically be completed within their desired time frame.
However, it is important to realize that in order for a project to remain Agile detailed timeboxing and schedule planning must only be done for the next Sprint or Iteration. More defined project schedule management is possible at this level because the scope of a Sprint or Iteration is fixed and can provide valuable information as to how the project is progressing as a whole [5].
The next section covers the review or retrospective process that is a core element of Agile frameworks but are most often implemented as post Sprint or Iteration retrospectives. These are Agile’s more flexible form of project schedule control as well as being a key part of developing a realistic project schedule [2].
Project Schedule Control and Adjustment
Remember how I mentioned humans aren’t very good at estimating things? Well, the good news is that since you’ll be reviewing the accuracy and viability of the project schedule frequently in Agile, you’ll know whether your estimations are off pretty early in development [6].
At the end of each iteration the progress made must be reviewed, compared against the expected progress, and if any of the iteration’s features weren’t completed decided whether they should be carried over into the next iteration.
The amount of finished and unfinished work is often visually represented in something like a burndown chart and can be used as a reference point to help indicate whether the project is on schedule and indicate when the actual implantation time of features is deviating from the high-level estimate.
Additionally, as more and more features are worked on they provide more concrete reference points that can be used to better estimate how long other features will take which improves the accuracy of future sprint plans [2], [6].
The act of planning out a Sprint or Iteration itself can also help teams conceptualize and think through the project schedule on a regular basis. This can be a helpful way to make sure time constraints taken into consideration by the whole team throughout the project [6].
Summary
Agile doesn't have project scheduling in the traditional sense but Agile does have some techniques for to help ensure a project successfully meets deadlines and can work for projects with semi-fixed time constraints.
Agile’s form of project schedule management uses a more defined project schedule for smaller short-term sections of development. This is often in the form of sprints or iterations and uses that information to form increasingly accurate high-level estimations about the schedule of the project as a whole.
Sources
Kommentare