Tag Archives: planning

Planning, whether in a programme, porfolio or project, or just part of product development

When To Measure Lean-Agile Productivity, and When Not To

Posted on by

Lean-Agile offers two productivity measures: Velocity and Throughput. It is possible to improve both over time but there is little point in management demanding that a development team improve either because both metrics are very simple to fudge.

There is also little point in using either of these productivity measures in product development. The focus is discovery not churning stuff out.

Where a productivity measure is useful is in a project or programme. Where somebody is wanting to know when the team will be finished. Or, conversely, how much functionality will be delivered before the time and/or money has run out.

Continue reading →

How to Manage a Vague or Dynamic Product Backlog

Posted on by

In response to my request for questions along the lines of what do I do when … ? Jo asked:

What do I do when the product backlog is not complete and we still want to deliver our product on the agreed date? It is hard for the Product Owner to prepare a complete feature backlog and for developers to estimate the required time in order to get a realistic burndown chart during the sprints. The product backlog is kind of dynamic.

In response I’m going to look at three states for the product backlog and strategies for managing backogs when in each of those states:

  1. Normally vague/dynamic
  2. Completely vague
  3. Massively dynamic

The first of these states is, well, normal. You never know everything about the scope. You just have to manage what you do know.

The other two states suggest something is going wrong in the product management space. And that is very much a product owner issue. The agile project manager / scrum master role is to help the product owner and/or organisation realise their problem.
Continue reading →

What do I do When Tasks in the Sprint Plan are not Finished?

Posted on by

This is what having a large number of tasks unfinished at end of Sprint looks like:
Over commitment burndown

Not pretty.

It is best to avoid over commitment so the answer to “What do I do When Tasks in the Sprint Plan are not Finished?” is to lower your expectations next time you go into planning. Using Scrum language you should ensure the team only commit to what is achievable, and that is obviously less than they thought was possible the last time around.

You’ve also got to tidy the up the mess left by the previous Sprint. Have a look at the unfinished tasks and decide if they are necessary for your high priority user stories. If so, then schedule them into the next Sprint. If not, then forget about them.

Finally, you have to decide what credit you can give yourself, i.e. what velocity you earned in the previous Sprint. Personally I start hard line about this. You can only claim a user story if it is completed, so you can only add the story points for that user story if all the tasks have been completed. No partial credit.

Having said that:

  • If you find that the unfinished tasks are actually unnecessary then you can claim credit for the whole user story.
  • It is sometimes possible to split a user story into meaningful sub-parts. If one of the sub-parts has been completed then you can claim the story points of the sub-part for velocity

This post is part of my What do I do When … ? series. Please drop me a line or add a comment if you’ve got a question you’d like answered.

New Agile Teams and the Overcommitment Bear Trap

Posted on by

The most common problem I’ve seen with software development teams is over commitment. Invariably individuals and teams are overly optimistic about what can be done in a certain time period. There are any number of reasons for this including arbitrary management deadlines and the team not pushing back, the developers desire to please, and just the fact that estimating in software development is hard.

Agile development teams are just as prone to this problem as any others. Every team I have helped transition to Agile has stepped into this bear trap almost immediately. And forewarning them doesn’t help. I now see stumbling into the trap as a valuable lesson and an essential step in the process of getting more mature about software development. I don’t mean maturity in the sense of the SEI’s Capability Maturity Model, I mean maturity in the sense of growing up, being realistic and accepting the limitations in themselves, their team and the organisation.

The difference about Agile, compared to traditional approaches to software development, is that Agile offers techniques to avoid the over commitment bear trap.
Continue reading →

Reinforcing Success in Products and Projects

Posted on by

A fundamental military axiom is to reinforce success.

Reinforcing success is a strategic concept used in many areas of decision making and management. Originally a military doctrine, the term is also used in theories related to parenting, business and other fields. It is essentially a selection criterion, or a prioritizing principle. A course of action is selected from various options on the basis of previous results of similar actions. The basic idea is: if it works, keep doing it; if it doesn’t, don’t invest more in something that’s failing.

Wikipedia: Reinforcing Success

I believe businesses should apply this principle to projects, products and product features. So not surprisingly I apply this as a guiding principle in my own work as an agile programme manager.
Continue reading →

Agile Project Estimating

Posted on by

Estimates are an essential part of Agile Project Planning.  Software estimation has always been problematic and people have proposed many different ways to do estimating.  Different methods are on a spectrum from formal to informal and from supposedly objective to seemingly subjective.  Different methods also get individuals estimate or groups.  And some methods estimate size and derive effort while others estimate effort directly.  Estimating in the Agile world has settled a certain approach which might be characterised as expert group estimation of size. this article covers Traditional Project Estimation, Agile versus Traditional Estimating, Estimating User Stories, Estimating Tasks, Contingency, and Agile Ballpark Estimates.
Continue reading →

Agile Project Execution

Posted on by

Executing is one of the five project management process groups in the Project Management Body of Knowledge (PMBOK) from the Project Management Institute (2004).

Project Execution is where you build the project deliverables and hand them over to your customer, i.e. where you build and deliver the software. This is where most of the project effort is invested. Agile Project Planning says what you intend to do, when, and Agile Monitoring & Control helps you stay on track but Agile Project Execution is where you do the business.
Continue reading →

Agile Project Monitoring and Control

Posted on by

No battle plan survives contact with the enemy

Field Marshal Helmuth Graf von Moltke

Life is what happens to you
while you’re busy making other plans

John Lennon

Agile Project Planning tells us what we expect to do, but, to paraphrase the quotes above, plans often turn to custard. The job of the Agile Project Manager is to guide the team to successful delivery despite the challenges the world throws at the project. This article is about monitoring the project against the plan and intervening when we notice things going off track. In particular it covers Traditional Project Monitoring & Control, Agile versus Traditional Monitoring & Control, Agile Project control, Agile project metrics, Agile Project Reporting, and Agile Project Monitoring.
Continue reading →

Agile Project Planning

Posted on by

No battle plan survives contact with the enemy

Plans are nothing, but planning is everything

Field Marshal Helmuth Graf von Moltke

I believe that Agile Project Management provides certainty of delivery. Planning is what lets us answer the question “When will you be finished?”. Planning is, however, just the start of the process. As Moltke pointed out planning is more important that the plan because once you start the project you’ll find the plan is wrong and you have to adapt. All plans need revisiting and you will have to use Agile Project Control, Agile Change Management, and Agile Risk Management to get the promised certainty of delivery.
Continue reading →