Agile Software Development

The adaptation mechanisms built into the Scrum process allow for many modifications and adjustments in the sprint planning procedure. Different variations work for different teams and environments. Here is one of the variations that I find useful:

Preconditions

Product backlog contains a set of user stories sufficient for at least 2-3 sprints, ideally - for the whole current release and more. The team together with the Product Owner and possibly with some stakeholders went through the top stories 2-3 days earlier. As a result for a sprint or two there are enough reasonably small and well understood top priority product backlog items.

Advertisement:

User Stories are a not mandatory, but very recommended part of Scrum and eXtreme Programming methods. Most of people acquainted with agile software development feel comfortable with the requirements written in the form of "As a [user role] I want to [goal], so that [reason]". Less people are acquainted with epics and themes usage.

Terms

Epics are just huge stories for capturing relatively low priority requirements that are often too complex to estimate right away and that are going to be detailed later. An epic for a car could be "As an environment conscious driver I want to be able to use both gas and hydrogene". A theme on the other hand is a set of stories grouped around some functional area, user group or anything else that makes sense for the product owner. Themes are often confused with epics, because quite often the epic is split down into exactly one theme. A theme for a car could be a set of stories grouped around the building the hydrogen engine.

Bridgekeeper: “What is the velocity of an unladen swallow?”
King Arthur: “An African or European swallow?”
Bridgekeeper: “Huh? I don’t know that…”

- Monty Python and the Holy Grail

One of the most important metrics of an Agile team is its velocity. (No, you don't have to give the receptionist a stopwatch and do laps around your office.) In project management terms, velocity is the amount of work that a team can complete in a specified period of time.

Agile methods significantly differ from the traditional waterfall-like methods. Agile teams don't need a half a year of requirement analysis and design before the coding phase, most of the tests are written by programmers and are automated, customers are asked to participate, try live software and provide feedback frequently. All these peculiarities as well as inability to commit to the concrete set of deliverables early sometimes make agile methods look fluid and unpredictable - something not valued by the business people.

However, agile methods have a reason for not committing to the end result in the beginning of the project.

Agile teams try to avoid the over-detalization of the customer requirements. In many cases the initial requirements are specified as loosely as in one sentence. In order to keep focus on the real customer demand (and not on what dialogs he'd like to see) the feature requests are often expressed in a form of "As a , I want [so that ]". For example, "As a network administrator, I want to monitor the most active nodes of the system so that I was able to easily balance the load". This form of requirement works very well until you start to work on it. It allows for capturing the original user need, while delaying the implementation specifics as long as possible, so that the team was able to work on it with as much information as possible.

When talking about software development, often the building construction analogy is used. As every other analogy out there, it is not very accurate. Unfortunately this particular analogy is inaccurate in a very important way. Buildings are the artifacts of the material world, while software is non-material.

The virtual nature of software allows for the transformations impossible in the physical world. In the physical world there might be a possibility to add balconies to the existing house during the expensive renovation, but it is impossible to add a hundred floors to the the two-storey house, just because the grand city architecture plan changed and it is now possible to get bigger return of investment by building a sky-scrapper instead. It is impossible to adjust change the floor plan just before roofing in.

Agile software development methods are sometimes criticized for the inability to rely on. Agile project managers are unable to produce the fixed upfront effort-time-costs estimation. Sometimes it is even the core argument of the waterfall process proponents.

In fact agile manifesto principles "Customer collaboration over contract negotiation" and "Responding to change over following a plan" do not state that contracts and plans are useless. Agile community recognizes the value of contracts and plans, it is just so, that the agile developers value collaboration and responding to change more. If there is a possibility to create the upfront time and costs estimation, the agile team

Any plan is in essence a sequence of actions to be performed in order to achieve a particular goal. Plan acts as some kind of a contract that specifies the agreed way of reaching this goal.

Keeping the plan can be both harmful and useful under different conditions.

In waterfall-based processes people try to specify to death everything before the actual development starts. Plan creation takes huge amounts of time and efforts. Replanning would require similar amount of work. It also might introduce the half-completed features since in waterfall there are no completed features until the very end of the project. No surprise, that waterfall-based processes avoid plan updates as much as possible.

Most if not all of the agile software development processes are based on the assumption that it is hardly possible or not possible at all to predict the real requirements and real workload size at the beginning on the project. The whole idea of agility is to try implementing the most critical stuff, see how it goes, get customer feedback and adjust the close plans.

Such limitation of the upfront planning minimizes the amount of time wasted on never used overplanning and on developing features, that after later consideration happen to be wrongly understood or unnecessary at all. Also the detailed plan non-existence welcomes changes easier. If there are no planning results to modify, there is no temptation to just follow the obsolete plans.

High accuracy, low precision

High precision, low accuracy

Any plan is in essence a set of steps to perform in order to reach a given goal. Every goal and task has two important, but unfortunately often mixed characteristics: accuracy and precision.

Precision tells about the level of the detalization. A promise to make your database handle four simultaneous requests tomorrow at 9:30 is a very precise promise. A promise to make it handle hundreds of requests sometime next year is not very precise.