Projects are a necessary evil :-) But necessary they are.

Some people really feel the need to understand precisely what the project will cost and exactly long it will take. If this is the basis for investment, of course that's a completely understandable feeling.

For years, traditional waterfall projects have been sold on the false pretense that projects are predictable. Plannable. Of course the reality is, projects are highly unpredictable, and - sadly - that's why so many projects fail to meet expectations.

So when you need to plan a project, in order to forecast the overall costs and timescales, how do you do this for an agile project?

Well, of course, agile development is no silver bullet.

If you are bad at planning, bad at identifying and sticking to at least the broad scope of the project, bad at estimating until you have all the details, bad at controlliong delivery, an agile project plan is likely to be just as bad as a non-agile one!

The benefits of agile development are more to do with early realisation of business value, early visibility when things are going off track, collaboration and regular feedback to ensure quality and provide the right solution, and so on.

Yes, there are also some important benefits in the approach to estimating, but fundamentally, planning a complete project up-front and committing to costs and timescales is still, of course, a potentially potted process. A process full of pitfalls. And a process that requires great skill and experience to get anywhere close to predicting something that will resemble reality.

But, with that caveat in mind, here's how agile project planning works...

Agile project planning is generally referred to as 'release planning'. The concept of an agile release plan is about planning multiple Sprints that culminate in a release of the product. It is not necessarily project-oriented, however the concept for projects is of course the same.

PRODUCT BACKLOG

First of all, you really need to get your Product Backlog in order!

The Product Backlog is essentially a feature list. Above all, it's user-oriented and lists features in a language that business people and users understand. It's not technical. And it's not a list of tasks. Do not attempt to list all the tasks for the project and identify all the dependencies. Just list all the features the project needs to deliver.

Also include any lasting deliverables that are not necessarily part of the software. For example a User Manual, or a Technical Reference Document for any API's. However do not list the *temporary* deliverables that are just part of delivering a feature. For example don't list the analysis tasks or design documents for each feature. Try to keep it as a list of product features and only include deliverables that outlive the project.

What I'm about to say is an important point about any planning process, whether it's agile or not, so listen up! :-)

There are generally only two things that cause your plan to fail: 1) You under-estimate the things you've identified; and 2) you don't manage to identify everything . If you only estimate the items you identify, the quality of your Product Backlog is a critical success factor for your project.

BUSINESS ANALYSIS

So surely I have to do a complete analysis up-front to make sure I've identified everything, right? Yes and no. If you're going to plan a complete project, even if it's an agile project, you do need to do *enough* analysis to identify all the features you think you need to deliver.

However, unlike in a traditional analysis with a specification, you really do not need to identify all the details about how each feature will work. Just enough analysis to list all the features, with a degree of confidence that the broad scope of the system is covered. The details can be left until later, and be dealt with just in time for the feature to be developed.

So it's very important that the Product Backlog is at an appropriate level of detail. This, in itself, is a mysterious art. If the items are too detailed, and you estimate only what you've identified, there is a high chance you'll miss some things out. But if the items are not detailed enough, there's a high chance your estimates will be wrong.

Because agile estimating (which I'm coming on to) is based on broad, relative size of each feature, you do not have to break down the features too small at this early stage when trying to estimate the overall project.

For example, it's probably sufficient to know that users will need to be able to register and log in. It's probably not necessary to itemise what details they will need to enter to register, and how the system will authenticate the login. Unlike traditional projects, you certainly don't need to worry about how long will the fields be and what validation will be needed, and minor details like that. The details can be sorted out later.

When you are reasonably confident you have a comprehensive Product Backlog that broadly covers the scope of the project, listing all the features that need to be delivered by the project - not too detailed but detailed enough to compare the relative size of each feature - you are ready to do your estimates.

ESTIMATING

First of all, do your estimates as a team. 'Planning poker' is a method where each team member writes their estimate on a card and all team members reveal their estimate at the same time. This is quite fun to do and is a great way to get everyone's estimate before they are influenced by others. Wild discrepencies in people's estimates are a great discussion point, a way to identify differences in understanding early on, and a way to understand different people's perspectives about the implementation.

Secondly, estimate your features in points. Many agile teams use the Fibonacci numbering system to do this. The points represent the relative size of each feature. For example, a feature with a 2 is roughly twice the size of a 1, which is very simple. A feature with a 5 is a bit more than twice the size of a 2, and a 21 is much more difficult.

Basically it's the relatively of this estimating approach that is important, not the number itself. The philosophy is that people can't really tell you accurately how many days or hours it will take to implement something they know little about, but they can tell you whether they expect it, on average, to be easier or harder than something else.

When the whole Product Backlog has been estimated, you now know the 'size' of your project, but it's in abstract points rather than in real units of time. How do you convert this into a cost and timescale?

PLANNING

If you are going to utilise an existing team that are already doing agile, and you know their average Velocity per Sprint, it's easy. Just calculate how many Sprints it would take to burn-down the number of points on your project's product backlog.

If, however, you're establishing a new team, that has not done agile before, you have no idea what their Velocity might be and this is another potted part of the planning process. Basically you need to make an assumption about the team size and its Velocity. In this case, this how I would do it...

Get more than 1 developer, of varying skill and experience, to look at a small section of the Product Backlog. Ask them how much they think they could complete in a single Sprint. Remember to explain what you mean by complete, i.e. done means DONE!, so you know everyone is working to the same basic assumptions.

Compare the number of points each developer has effectively said they can complete in a Sprint and decide what you consider to be a reasonable average based on what you've heard. Using that average number of points, assume that's your Velocity (per person) and calculate the number of Sprints you would need to complete the entire Product Backlog. This calculation will give you your approximate project duration based on 1 developer.

SUMMARY

Now you can make an assumption about the size of your team, based on the available people, the target timescales or the amount of funding you could potentially raise, and cost it up accordingly.

As with all projects, it would be wise to add a contingency. As I mentioned earlier, it's often the features you didn't list that cause a plan to fail. The contingency should reflect your level of confidence in the quality of the Product Backlog. If you think it is thorough, and the project is unlikely to be prone to lots of change, maybe you should add about 10-20% to your project. Otherwise it might be wise to add more.

Remember, though - although agile estimating and planning does have some distinct advantages, it is not a silver bullet. The care and attention you put into this process, along with the skill and experience of your team, in the end will really determine how likely your plan is to succeed.

Kelly.

P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...

read more

A software release may result from multiple iterations (or 'Sprints' in Scrum).

Sprint Planning is about planning what's included in the next iteration.

Whereas Release Planning is about planning multiple Sprints, in order to predict when a release (or releases) might be delivered.

Release Planning is a very simple way of doing some top-down planning. Much less complex than a more traditional project plan on a Gantt-chart. Therefore much quicker to do. And, I would say, no more or less accurate.

First of all, let's assume you already have your Product Backlog (feature list), with all your User Stories set out in priority order. Let's also assume that you've estimated your product backlog, ideally using Story Points.

If you already have an established team doing Scrum or XP (eXtreme Programming), use the team's known Velocity to divide the Product Backlog into Sprints.

However, if the team is not already using Scrum or XP, you need to estimate the team's Velocity. To do this, you must first make an assumption about the team size that is likely for the release. Then, you need to decide on your Sprint duration and, ideally with the input of the team, decide how many of the initial User Stories you think could reasonably be achieved in a Sprint. Add up the Story Points for these items. Using this number of Story Points as the team's estimated Velocity, divide the Product Backlog into Sprints.

If the project team is not already established, add a 'Sprint Zero' at the beginning to get things ready for the first Sprint, for instance getting the team organised, briefing meetings, setting up development and test environments, preparing the first set of User Stories, etc.

If it's a large or complex release, add a 'Stabilisation Sprint' (or more than one Sprint if appropriate) at the end to stabilise the release. By this, for instance, I mean stop adding new features, complete regression testing, bring the defect count down to an acceptable level, prepare for deployment, etc.

If the predicted end date is not acceptable for the project's objectives, alter the assumption about the team size (and associated costs!) and re-calculate.

And there you have it! A Release Plan that provides an outline of the Sprints, what's included in each, and an estimated date for the release.

read more

If we accept the above formula, why in non agile development methods is there so much emphasis on analysis, planning and change control?

High level planning, such as a feature list (or Product Backlog in Scrum), and an outline plan based on the affordable team size; Yes. Otherwise you've no idea what you're in for.

read more

In a few entries on my blog, I have referred to Velocity and only briefly explained what it is. I think it's about time I explain properly for those not familiar with it.

Velocity is terminology from the Scrum agile methodology and is basically the same concept as Earned Value in more traditional project management methods.

This is how it works...

1. Select a regular time period over which to measure Velocity. If you're using fixed Sprints or iterations, use that time period. Otherwise you can use weeks, fortnights or months. It doesn't really matter which as long as you're consistent.
   
   
2. Add up the estimates for all the tasks/deliverables/features in your chosen time period. It doesn't matter whether the estimates are in days, hours or even in relative points.
   
   
3. Only include the estimates for any items that are 100% complete and signed off within the time period. Anything still in progress counts as zero, as there is no value in incomplete work.
   
   
4. At the end of the chosen time period, the figure you have is your Velocity (or Earned Value).
   

You can then use your Velocity as a basis for your future commitments. As a result, it is self-correcting.

For example, let's say you estimate in hours and track your Velocity in 2 week Sprints. You know, therefore, there are 70 hours available in a Sprint, but find you tend to deliver a Velocity of 50 hours (because of under-estimating and other interruptions throughout the day). Tracking this trend will allow you to commit to your 'norm' of 50 hours per Sprint in future, because you know that's what you usually manage to achieve.

As a consequence of this approach, you don't need to be any good at estimating, and don't need to get any better at it. As long as you're consistently bad, you will still get better at delivering on your commitments.

In my experience, it's just as common for people to over-estimate by being too cautious. Velocity is also self-correcting this way around...

If, for example, you find you tend to reach a Velocity of 90 hours in your 70 hour Sprint, you are probably not a super-hero code warrier that eats problems for breakfast. You are probably just being too cautious in your estimating. In this case, in future commit to 90 hours. This might sound counter-intuitive, but go on. I dare you :-)

Although Velocity and Earned Value are project management techniques, why not know your own Velocity. If you do, you'll find you can gauge much more accurately how much work you can really commit to. Even if you're lousy at estimating!

And guess what? Everyone loves someone who delivers on their promises.

read more

One technique used by agile development teams is the idea of estimating product features using points. This has a few distinct advantages over estimating in physical units of time.

1. Estimating is very quick because it's an intuitive estimate of a feature's size.

2. An estimate in points indicates a feature's size relative to another, and does not give the illusion of being precise.

3. Over time, and using consistent iterations (e.g. 2-week sprints), you get a strong feel for how many points a team can deliver in an iteration. Even if a team is bad at estimating, as long as they're consistently bad, this makes a team's commitments self-correcting.

read more

Once you’ve completed Step #3 and clarified the requirements for all the Product Backlog items targeted for your Sprint, the next step is to plan the Sprint in detail…

read more

If you've followed the first 2 steps in this series, you should now have your product backlog in order and have estimated its size using Fibonacci points.

The next step - Step #3 - is to plan your Sprint.

Sprint Planning Workshop

Call a Sprint Planning meeting. Make sure the meeting is attended by the whole team. Include all roles. Business Analysts if you have them. Testers if you have them. ALL Developers on the Scrum team for the product. And very importantly the Product Owner.

The first thing you must do (in your first Sprint Planning meeting) is decide on your Sprint duration. This decision should be taken as a team.

Decide Your Sprint Duration

This is an important decision. Scrum suggests 30 days. It might be right. But this is one point that seems to be widely adapted by agile teams practicing Scrum.

The optimum Sprint duration depends on many factors. Something I read recently suggested that a development team's 'cycle time' is a direct reflection of the maturity of their processes. I think I would agree with that statement.

A team with immature processes will find the intensity of Scrum and the overhead of Sprint Planning, Testing, Deployment and Review quite onerous for a short Sprint cycle. Whereas teams with very mature processes (for example automated testing, automated deployment, and teams who've become very quick at Sprint Planning), a short cycle might be very comfortable.

I'd suggest the range is between 1 week and 1 month. 1 week is probably the shortest that will ever be practical, although if you really master agile practices, why not ship each new feature when it's ready? (if that's appropriate for the product). 1 month should certainly be the longest.

For fast-moving products or markets, such as web-based products - where there is central deployment and no rollout or user training - 1 month seems like a lifetime! Personally I like 2 week Sprints for fast moving products.

Mike Cohn is one of the key exponents of agile development. See here for Mike's article giving further advice about how to select the optimum iteration length.

Keep Sprint Duration Consistent

read more

In step 1 - my first article in this series - I described 'how to get your backlog in order'.

If you've completed step 1, congratulations! Because it's the biggest step. And the foundation for all else that follows. Whether or not you implement Scrum.

If you haven't completed step 1, you must not go any further until you have.

So here's Step #2: How to estimate your Product Backlog...

High Level Estimates

You need to provide some high-level initial estimates, in order to get an idea of the size of your product backlog items.

This is helpful because it helps to inform the decision about priorities. And whether or not the features are likely to be worthwhile. And from a management point of view, gives a perspective of how big the team ought to be, commercials permitting.

But as yet, you don't know much about the items on the backlog. You don't know exactly what the features are meant to do. You don't know what tasks are needed to complete them. And you don't really know how you will implement them.

So you have to do a very high level, top down, indicative estimate. In fact it's a guestimate. Not an estimate at all really.

How many times have you heard someone say, 'don't worry, I won't hold you to it; I just need a rough idea'? And of course they do hold you to it. Of course they do!

Estimate Product Backlog in Points

The answer: Estimate your product backlog in points. Not in units of time.

Repeat: Estimate your product backlog in points, not in units of time.

No, I haven't gone mad. I know it sounds a bit whacky. But I'm going to ask you to trust me on this one; it does have its reasons, some of which will only become clear later in the series.

In the meantime, I ask you to accept that development teams are more readily able to give guestimates of 'size', without giving an estimate in time that they might be held to, and without having all the gory details.

So we're not asking the team 'how long will it take?'. We're asking 'how big is it?'

I also ask you to accept that Product Owners are more inclined to take this as a guestimate - as it's intended - and not as a premature commitment.

Now I realise that points could be seen as useless to a Product Owner in terms of making a business case for funding. Certainly until a team has a track record and we know roughly how many points they tend to deliver in an iteration. But I'll come to that later. Certainly, it is still helpful for prioritisation and to get across the relative size of a feature to a Product Owner.

Use a Points System

So what scale should you use for your points system?

Personally I like Fibonacci numbers.

For clever people, click on the link above to understand what Fibonacci numbers are all about. For simpler people like me :-) they're basically a sequence of numbers that some very old and very clever people (generally Italian, as per usual) have worked out have a slightly spooky, but very scientific significance. And this significance all relates to physics and the laws of distribution.

More about Fibonacci is really beyond the scope of this article, but they are a scientifically significant set of numbers, where each number is the sum of the previous two. They are:

1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987 ...

For the sake of simplicity, when using these numbers for indicating size, I would suggest you use the range 1-21. Certainly for bug fixes and enhancements on products in the BAU (Business As Usual) cycle, this should give you sufficient a range. Maybe reserve 987 for that daft request you get sometimes to fly to the moon and back in an ice-cream carton :-)

The key here is about relativity.

A backlog item describes a feature. Maybe, for example, it's a report. You've done similar reports before, but it does have some complexity in the underlying data, so you decide to call this a 3.

Next on the backlog is another report. You size this one relative to the other one. Is it bigger or smaller. Clearly 21 is a lot bigger. 2 is a bit smaller. And so on.

To make sure the scale works for you, I suggest you start by picking what you think is the smallest thing on the backlog. Give this a 1. Then find the thing you think is the biggest thing on the backlog. Give this a 21.

Now you have your markers, size the backlog, working from the top, using the Fibonacci numbers.

When you get further down the backlog, you'll get to a point where the items are really rather fuzzy. And rather low priority. In fact you not sure you'll ever get to them in your lifetime. Please don't feel you have to size the entire backlog. Size enough of the items to see you through the foreseeable future. Remember it's already been put in priority order. So make sure you work from the top.

Estimate as a Team

Size your backlog as a team. There's a whole philosophy about the Wisdom of Crowds. Two minds are better than one, etc, etc. If there are big differences, use this as a discussion point to understand why. Did one person see issues and complications the other person didn't? Did one person see a nice simple approach that others didn't?

Consider playing Planning Poker. This is a fun technique to ensure that people don't influence each other. Each team member writes their estimate on a card, and everyone shows their answer at the same time. It helps to ensure less experienced members of the team are equally engaged and are not over-influenced by more experienced team members. It also helps less experienced estimators to learn from others. And it helps to avoid stronger, more vocal characters having too over-bearing an influence on the result.

From this exercise, negotiate the size of each backlog item as a team.

Review Priorities

Once you've sized up the backlog - or enough of it - ask the Product Owner to have another quick look at priorities. Maybe now they can see the relative size of the features they've asked for, they might change their view of priorities. 'Wow, if that's a 21, I'd rather have the other stuff first', or 'if that's only a 2, let's get it in the next release'. If any priorities are changed, simply move the item's position in the order of the backlog.

Stick with the Programme

Resist the urge to adapt this step. Ken Schwaber's book 'Agile Software Development with Scrum', which is highly recommended by the way, says this: If you are not yet an expert in a subject matter (e.g. Scrum) do not attempt to adapt it. Scrum is an adaptive process. But you are in no position to adapt it until you know it well, and have experienced it in operation.

Sizing up your backlog using points in one thing I would encourage you not to adapt until you've tried it, and tried it over a period of several Sprints so you can start to see the effects.

Next in the series: Step #3: Sprint Planning/Requirements

Follow this series by email

See also:
How to implement Scrum in 10 easy steps:
- Step #1: Get your backlog in order!
- Step #2: How to estimate your product backlog
- Step #3: Sprint Planning/clarify requirements
- Step #4: Sprint Planning/estimate tasks
- Step #5: Create a collaborative workspace
- Step #6: Sprint!
- Step #7: Stand up and be counted!
- Step #8: Track progress with a daily burndown chart
- Step #9: Finish when you said you would
- Step #10: Review, reflect, repeat...

'Implementing Scrum' PowerPoint Presentation

10 Key Principles of Agile Software Development

read more

I recently posted an entry on my blog about how to prioritise quickly and intuitively.

read more

Scrum, and other agile development methodologies, provide a framework for managing software development projects.

But all too often, methodologies focus on a project environment, where the team is focused predominantly on a shared goal. Where the team is largely dedicated to the project.

In reality, this is often not the case.

In reality, development teams are frequently required to develop and support multiple products. Multiple products with multiple product owners. And particularly in 'business as usual' ongoing development.

So how do you share an agile development team?

Operating as a resource pool is often not ideal. Everyone throws their requests over the wall. Those that shout loudest get the team's attention. Or maybe the bigger products get the team's attention, at the expense of smaller products that never get to the top of the list, and never will.

Splitting the team by product sounds great. But sometimes the team's too small for this approach to be practical. Or it leaves too many individal developers, causing problems with cover and you can't exactly collaborate with one developer per product!

So what can you do?

We have a similar situation in lots of our teams. Broadly speaking we are solving it like this:

• There is one Product Owner per product. The Product Owner maintains a separate Product Backlog for each product.
  
• 
  
• The development team acts as one team.
  
• 
  
• The Sprint Budget (number of man-hours available for a Sprint/iteration) is allocated to each product based on our recharges, e.g. 60%-20%-20%. If you don't recharge, you could agree this at a more senior level as a general rule of thumb. Each product has a known % of the budget for each Sprint.
  
• 
  
• Use Cases/User Stories/features are broken down into Tasks and estimated by the development team during Sprint Planning.
  
• 
  
• Each Product Owner can only include Tasks from their Product Backlog up to their allocated % of the Sprint Budget.
  

This approach means the development team can act as one team. There is knowledge sharing and cover when someone is off, because in this case the overall Sprint Budget is reduced but everyone still gets their usual % share of the available hours.

It also means team members don't have to juggle their time between products on a 0.x FTE basis, which is awkward at best and just plain impossible when the fractions are too small or odd numbers.

Instead the Tasks allocated in the Sprint are already appropriate to the Sprint Budget per product, meaning team members can focus on delivering the Tasks in the Sprint, not worrying about how to split their time.

See also:
10 Key Principles of Agile Software Development
10 Good Reasons to do Agile Development
Top 10 Agile Development web sites

read more

If you're in a situation where prioritisation is straightforward and you have a single decisive product owner, you probably need to read no further.

If, however, prioritisation is difficult in your situation - maybe because you have several products or product owners with conflicting priorities, or maybe because your requirements can be complex and benefits rather intangible - this is for you.

In this case, prioritisation can be difficult and priorities are not always immediately obvious.

This simple approach might help you to prioritise more quickly and intuitively...

Draw a 2 x 2 grid. Use the bottom axis as 'Difficulty'. Make the vertical axis 'Importance'.

'Difficulty' should represent all the negative aspects, such as time, cost, effort, risk, complexity, etc.

The 'Importance' axis should represent all the positive aspects, such as revenue, cost-savings, and (slightly counter-intuitively) the risk of not doing it.

Make the left corner of each axis 'Low' and the top and right of the axes 'High'. What's in between doesn't really matter. 'Difficulty' could be your complexity points if your using Fibonacci estimating or something similar. But it doesn't really matter. The important thing is simply one item's difficulty and importance relative to anothers.

Plot each of your items on the grid, making an intuitive judgement about whether it's harder or easier, more or less important, than the other items already plotted. Make sure they're plotted roughly in the right position, relative to each other.

Get the relevant product owners to decide on the vertical position. Get the technical team to decide on the horizontal position. This is best done in a workshop with all the relevant people together. It's also important that only those qualified to judge should influence the horizontal position!

It's a good idea to start with the things that are clearly the easiest, hardest, most and least important. Place these in the corners of the grid to provide a useful context for other, less obvious items.

Once you've got all your things on the grid, think about the four quadrants. Things in the top left are "No-Brainers". These things are clear priorities. Things in the bottom right are potentially for the bin, as these things are of the least value.

Things in the bottom left are quite straightforward to deliver but not the most important. Consider ways to make them more valuable, i.e. push them up on the grid. Could they be chargeable features (if appropriate)? Or if enhanced slightly would they be considered much more important? Of course you shouldn't do this artificially; it's counter-productive.

Typically things in the top right quadrant are more strategic developments. Although they're over to the right, if you never start them you'll certainly never deliver them. Consider ways to simplify these items. Consider breaking them up into multiple things, so bits can move left on the grid and the strategic changes delivered over time.

This might sound like a simplistic approach, but you might be surprised how many things you're already working on that are not in the top left of the grid. And how many things you might not be working on, that are.

See also:

How to prioritise (Part II)

read more

The beauty of NOT doing agile development... is that failure comes as a complete surprise, instead of being preceeded by months of worry!

Often in traditional development projects, everything seems to be going so well, right up to 80% completion or perhaps even later.

Then things start getting harder...

Things start looking less and less likely to meet the planned end date. Until eventually you concede that you can't hit the date because it's just too late to do anything much about it...

In agile development, there are a few key principles that highlight such issues early. Distressing though this is, the issues are highlighted whilst there's still time to do something about it.

One reason why this is a common problem in traditional software development projects is because the testing is one big lump all at the end. Consequently it's very hard to gauge quality until late in the day and it's very hard to judge how complete the product really is, because you don't know how many more bugs there are to find.

In agile development, testing is integrated throughout the lifecycle, features are completed one by one, and for each feature "done" really means "DONE!". In addition the product owner or user representative is actively involved in order to see the product frequently and steer its development every step of the way.

All of these principles go a very long way to ensuring clear visibility of progress, and providing a clear and unambiguous measure of the product's completeness on a very regular basis.

But in addition to this, the Scrum agile development approach also offers a daily burndown chart that beats any traditional status report hands down!

The daily burndown chart is a simple tool. But it's also a very powerful one. Take all the tasks or features to be delivered in a particular iteration, or Sprint in Scrum. Put down the estimated time to complete. Update the time to complete each task on a daily basis. Be honest about what effort you believe is required to complete each task (that's complete each task), regardless of how long has been spent to date and regardless of what was estimated in the first place. Your goal, quite simply, is for the team to reach zero by the end of the Sprint/iteration.

The beauty of this approach is that it's a numeric view of progress and can therefore be plotted visually on a graph. Plot the original estimates for the Sprint on one line, and the current estimates to complete on another line. When the current line tracks below the original line, you're on track. When it tracks higher, you're running behind. Simple as that!

I've also found it useful to annotate the graph with 'speech bubbles' describing key events along the way. This is a useful way to record significant events so they're not forgotten by the time of the Sprint review, and it's also useful to communicate important things to management and stakeholders instead of producing a separate status report.

Using a burndown chart, when you spend one day on a task and discover a whole load of problems or effort you hadn't anticipated or estimated for, the estimate to complete jumps up, creating an all-too-visual indicator of the problem for all to see.

When this happens early in a project, and/or on a large scale, believe me it's pretty scary! Suddenly you're not so sure about all this new-found visibility. It seemed like such a good idea at the time, but can you really stick that burndown chart of the wall?!

But you do gain one big advantage. One enourmous advantage, actually. You get to see where the project really is, every day, and in all its techni-colour glory! And whenever you hit problems in a project, you actually see them, and see them when you might just have time to do something about it.

See also:
10 Key Principles of Agile Software Development
Testing is integrated throughout the lifecycle
Features are completed one by one
"done" really means "DONE!"

read more

One of the key agile principles is about fixing timescales and varying scope.

In DSDM (Dynamic Systems Development Methodology) these iterations are called Timeboxes; in Scrum agile management practice they are called Sprints.

For Business-As-Usual (BAU) changes to existing products, one Sprint may equal a release of the product. However for projects it's more than likely multiple Sprints will be required before the features have enough value to the user to be worth releasing.

In the case of projects, it's clear there must be some kind of release planning sitting over the individual Sprints. This is important to estimate how many Sprints are likely to be required before the product will be ready to be released.

Having done this release planning and worked out how many Sprints should be needed, probably doing some fairly high level estimating at the outset in order to secure project funding, individual Sprints cannot be run in isolation.

The danger if they are, is that any overhang - or personally I prefer to call it hangover :-) accumulates and creates a bow-wave effect towards the end of the project, and on some projects it's more like a tsunami!

Whilst the scope may be varied, and in agile development the scope should be varied, there does of course come a point when you simply can't vary scope any further without seriously undermining the basis of the original business case. And unfortunately it's at that point you're back to the good old-fashioned slippage, that is all-too-common and all-too-painful in so many software development projects using whatever methodology.

So how about BAU? Surely you can run individual Sprints in BAU, each leading to a release of the product? Yes, technically you can. But I say you shouldn't.

Just to clarify - yes, of course you can run individual Sprints each leading to a release of the product. But ideally you shouldn't run a sequence of Sprints in complete isolation, even in the BAU scenario.

The product owner, together with the product team and those responsible for the commercial results of the product, should ideally form an outline plan of sorts; a high level roadmap if you will. This is important as the basis for business planning, budgets, revenue forecasts, etc. And even if the planning is fairly unscientific at this level, there must be a clear business vision of the key drivers for the product over time, and this vision needs to inform the priorities of the Sprints.

See also:
10 Key Principles of Agile Development
Time waits for no man!
How can I be sure my project will deliver on time?

read more

In agile development the timescale is fixed. So one thing you can be absolutely sure about, is that it'll deliver on time!

The question in agile development is the other way up - how can I be sure enough features will be delivered to achieve the objectives and realise the benefits? And the truth is, that's still a really tough question.

Unfortunately, no methodology - agile or otherwise - can completely mitigate the risks of software development, because it's inherently a potent cocktail of unpredictability (people, software, estimates, change).

However agile development does provide clear, measurable, visible progress on a frequent basis, so it goes a long way in mitigating risks and identifying issues early, while there's still time to react.

See also: Time waits for no man!

read more