MoSCoW planning poker

Backlog refinement

One agile practice that we’ve adopted from Scrum is that of product backlog refinement. In short, it involves representatives from both the project level team (project manager, business visionary, technical coordinator, etc.) and solution development team getting together periodically to review the prioritised requirements list (the backlog) to decide whether the upcoming features still have the same priorities, given what we’ve learned throughout the project so far.

This isn’t an entirely alien concept to DSDM, which recommends that “at the end of a project increment, all requirements that have not been met are re-prioritised in the light of the needs of the next increment” (DSDM 2014 onwards, paragraph 10.4.4). It simply gives it a memorable name.

As we approached the final two sprints of the digital pattern library (DPL) project (DC1001/2) we found ourselves with quite a few new requirements that had emerged from the work we had completed so far on the DPL. Many requirements were little more than ideas jotted onto a Trello card, or non-critical bug reports. Most had not been estimated. It felt like the right time to take a couple of hours out of the sprint to begin to get things into order for the next one.

First, we read through the cards to understand what they were about. Then we prioritised them. And last, we estimated them.

For estimation we use planning poker cards, which I wrote about in this article: Planning poker—why and how we estimate. It’s a simple, democratic technique that quickly helps build consensus. So, building on that success we adopted a similar approach for determining priorities.

Continue reading MoSCoW planning poker

Agile release planning with multiple projects

One of the biggest challenges we faced when we started down the Agile path was how to accommodate working on multiple projects concurrently. This is a little insight into how we are currently managing ourselves across two projects plus business as usual tasks.

The Agile ideal

Most Agile/XP/Scrum literature assumes a single, cross-functional team working on a single project for a single customer using a narrow range of technical disciplines. The primary reason for this is that task-switching is really expensive: it is much more efficient to remain focused on one project.

That way of working, though attractive, is more or less impossible in our situation; something that I’ve also heard from other university digital teams. We don’t just work on projects, we have business as usual commitments (which include meetings, support calls, personal development, blogging, editorial calendar updates, etc.), consultancy (where we work on approved institutional-priority projects managed by other teams) and portfolio mechanics (board meetings and related admin, writing up project ideas and terms of reference documents, etc.).

After all that excitement has been deducted from our working week, we are generally left with only about 40% of our time to dedicate to pushing projects towards completion. We therefore need to be careful to extract as much value as we can.

Continue reading Agile release planning with multiple projects

The challenges of resource management in our Agile team

Over the last year, as we’ve been formally trying to work in a more agile way, one of the biggest challenges I’ve faced as a project manager is resource management. In other words,

  1. How do we know how much time each team member has to work on projects?
  2. When we’re planning the next sprint, how do we track how much work has been assigned to a team member, so that they have neither too little nor too much work.

Agile planning in theory

In theory, Agile planning should be pretty straight forward.

Imagine we have a team of five developers, each with 6 hours available for work each day. That gives us 30 hours per day, and assuming 9 days of project work (with one full day set aside for retrospective and planning) then within each two weeks sprint we should be able to dedicate 270 hours to development work.

During the planning session then, with the business having prioritised the work to be done next, it’s up to the development team to estimate the size of tasks and stack these up in a backlog. We know that we should aim for around 270 hours of work (or perhaps a little less, maybe 265 hours, to create some slack — breathing room to make provision for some tasks running on a bit longer than anticipated).

Moving through the sprint, developers pull work to themselves and gradually over the fortnight all 265 hours of work is completed.

Within a few sprints the team begins to establish a velocity—the average amount of work that can be comfortably completed. This really helps to plan further ahead as the team becomes both more predictable and reliable.

Continue reading The challenges of resource management in our Agile team

Agile planning poker

For a few months we’ve been starting to use Agile, and specifically Scrum, methods in planning and managing our Web projects at work.

This week we adopted a new practice: planning poker.

Agile / Scrum iteration planning board
Agile / Scrum iteration planning board

Like many teams starting out with Agile practices we didn’t just jump in feet first and adopt every Agile method going; that would have been too much to take in. So we began with a few methods:

The photograph above, taken a couple of months ago, shows the planning board in our office — an information radiator — that shows us at a glance how many tasks are left to do, what’s currently being worked on, what’s in testing, what’s done and (unlike, I would guess, most other Agile boards) what we’re waiting for.

Continue reading Agile planning poker