Tag Archives: estimating

Estimating software activities

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 →

A Lean-Agile Perspective at the Project Research Institute (part 2)

Posted on by

Last year I wrote a series of blog posts for the Project Research Institute of Athabascau University in Canada. As I mentioned before the PMI’s aim was to introduce their relatively mainstream audience to an Agile perspective. My aim was to show how the principles and practices of Lean-Agile Software Development offer creative solutions to general project challenges.

The PMI has now published all of my posts, including:

  1. Why Lean-Agile is relevant to all Project Managers
  2. A Lean-Agile Perspective on Project Governance
  3. Managing Complexity with Agility
  4. Empirical Project Management: Agile estimation and being “Done”
  5. Agile Experiments in Self-Organization

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 →

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 Change Management

Posted on by

My background is running Agile projects for external customers in the context of a contract, often fixed price.  That influences my focus on good project management and specifically change management. Change Management is the mechanism to combat scope/feature creep.

Within the Agile world scope change is expected and time is considered more important than functionality. So if something has to give to allow change then functionality/scope loses and time wins. To do this the customer must make Requirements Trade-offs. The Customer directs development in Timebox and minor changes are just accepted. Big changes are handled different depending on whether it is a change to the Release Plan or Timebox Plan.
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 →

Agile Project Scope

Posted on by

According to Wikipedia: Project Management project scope is:

The overall definition of what the project is supposed to accomplish, and a specific description of what the end result should be or accomplish.

We can talk about what is “in-scope”, i.e. what the project is meant to delivery, and what is “out-of-scope”, i.e. what won’t be delivered.

Typically the project scope is a subset of the scope of the product under development.
Continue reading →

Agile Project Initiation

Posted on by

One company I worked with called the start of the project the “Blueprint” as it is about roughly shaping the project and product. “Inception” is another common term for this phase in agile projects. This article outlines traditional project initiation then delves into more detail on Agile Project Initiation.
Continue reading →

Agile Risk Management

Posted on by

Risk management is about identifying, addressing, and eliminating sources of risk before they become a threat to the project. This article outlines traditional risk management, how Agile is a risk mitigation strategy, and how to do Agile risk management.
Continue reading →

One Page Agile Standard for team of 350

Posted on by

For the last two years I have been rolling out a standard Agile approach to a department of 350. One part of the roll out strategy was to have a published standard. This was to make the goal / end-game obvious even if we didn’t initially mandate everything.

The first version of the standard, published Oct 2006, was a 50 page document. Earlier drafts had been quite short but in reviewing the document people kept asking “What does that mean?” so we’d add another section explaining it. All rather worthy but, aside from the initial reviews before publication, nobody read it. And it diluted the document as a standard, defining what must be done, as opposed to a guideline about how to do it.

We published version 2 today. This version of the standard is one page. I want to give people a simple checklist so they know whether or not they are following the standard.
Continue reading →