Three Talents of Great Project Managers

During the last year I have spent a lot of energy on recruiting project managers. I was looking for something specific and although I spoke to a lot of project managers, some of whom came highly recommended, it took a long time before I found what I was looking for.

Having spent a fair bit of energy on this, I thought I’d write up what I believe makes a great project manager.
Continue reading

Correcting Overcommitment during a Sprint

As I’ve said before the most common problem I’ve seen with software development teams is over commitment. If worse comes to worst you get to the end of the spring before realising the problem. But you don’t have to wait until the end of a sprint to take corrective action.

Taking Corrective Action mid-Sprint to address Over Commitment

Taking Corrective Action mid-Sprint to address Over Commitment

This post was prompted by a comment, by Chris, on the post where I described what to do when tasks in the Sprint Plan are not finished. My assumption in that post was the team only realises they are overcommitted at the end of the sprint. And for first time teams that is often exactly what happens.

What I didn’t mention is that more mature teams are likely to spot what is going on earlier.
Continue reading

How to Manage a Vague or Dynamic Product Backlog

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?

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.

Programme Management: Build capability, Roll it out, and Deliver Business Benefit

Some people view programme management as simply the management of multiple projects (see for example Johanna Rothman: Defining Program Management and How Agile Helps).

Although programmes often comprise multiple related projects this definition, for me, misses the real point. As I see it programme management involves three things: building capability, rolling it out and, most importantly, delivering business benefit.

Continue reading

Nine Common Strategies for Managing a Growing Defect Backlog

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

What do I do when the defect backlog keeps growing with low impact (and low priority) defects and nobody seems to pay attention to them as we have more important features (or medium/high) priority defects to deal with? Should we deal with it or just stop logging low impact defects?

Faults are an inevitable part of software delivery. I only briefing touched on managing lists of faults in Agile Project Execution so it is well worth expanding on.

In fact defects is an area where software delivery, including agile software development, can get messy. Luckily there are ways to manage this mess or to avoid it altogether. Jo’s question hints at potential answers but there are others. In fact I know of at least nine common strategies for managing a growing fault list.
Continue reading

Reporting Success Stories Alongside Formal Benefits

Ever since I read "Made to Stick" by the Heath Brothers I’ve been a keen collector of success stories about my programme.

As the programme manager I have to report on the progress of my team. Risks, Issues, Budget, Milestones, Financial Benefits, Reach, etc, etc. Lots of numbers and facts. Terribly significant and rather dull.

So, to spice things up, I also report on success stories.
Continue reading