I’m speaking at Scrum Australia 2013

I'm speaking at Scrum Australia 2013

I’m happy to announce that I’ve been selected to speak at Scrum Australia 2013, in Sydney on April 10th.

The session is called “Keep on Trucking. An experience report“, and is going to be based upon the time I spent helping with the Scrum training of the development team at Toll Global Logistics, coaching them through their first projects startup, and advising the Development Manager, Risto Pearce.

Risto will be joining me in a “fireside chat”, Q & A session.

The general categories we are covering are:

Origins: What is involved in transitioning to agile in a corporate IT environment?
Training: What type of training was undertaken?
Implementation: How and what happened when implementing agile?
Evolution: What happens after a department has been using agile for a while?
Beyond: How agile affects other parts of a company.

Free download: Product Backlog Creation Guidelines

I was once asked to draw up some guidelines to help steer a team through starting up an agile project. They wanted to have a clear understanding of what was needed to create their initial product backlog. So I fired up Omnigraffle and came up with a few pages that gave an outline for that particular team.

Image of Flow for Product Backlog Creation

The 3 page PDF covers the following.

  • a page with a summary of the phases involved in the process of Product Backlog creation
  • a basic Flow diagram, that you can see above
  • a page with descriptions of some potential roles/capabilities.

IMPORTANT! – this is a guide only, not a template. It was created for a particular condition, and it should be assessed and adapted to your conditions. I have adapted it slightly and posted it here in the hope that it might be useful if you want to give someone an overview of what starting up an agile project might look like, or to help you if you want to get an idea of what might be involved.

Whatever ends up being right for you, the emphasis should be on communication…doing the right things at the right time, for the right reasons; and making sure that the right people are involved at the right time.

The Phases of Product Backlog creation

Here’s a short description of the phases that are included in these guidelines.

Theme ordering/priority

With Product Backlogs, we often talk about the different items as User Stories, Epic Stories, and Themes as a way of helping to organising the different things that a user would do in a finished project. Some people think of Themes as “collections of user stories“. This is OK, however I have tended to think about Themes as high-level categories from which smaller user stories will be created. At least before many/any User Stories have been created.

For example, “We want to Browse for products, Search for products, See Detail about products, Compare products, Select products to buy, and Pay for them”. So in this case, Browse, Search, Detail, Compare, Select, and Buy, would be the Themes. Some of these we want to do first, or need to do first. This is known as Ordering. It has been known as Prioritization but that Ordering is now the more accepted term. We’ll take the Themes that we want to work on first, and break them down so that they can be developed. Some of the themes won’t be done for a a while, so we can put them aside for now.

Phase 1 – Story Creation

Our goal in this phase is to come up enough User Stories to be able to take them into development and come up with an increment of our product that is tested, working, and might be something that will be usable. Sometimes, there will be some User Stories that have emerged already, sometimes there are just the high level umbrella themes. In this phase let’s get more User Stories out there that we might want to work on imminently.

Phase 2 – Story ordering

We talked about ordering Themes earlier. In this phase, we are talking about ordering the stories that we came up with in the previous phase. It could be that our creative juices flowed so much that there is more work than can be done right away, or that we’ve come up with stuff that we definitely can’t, or don’t want to implement right away. This phase is about surfacing the things we definitely want to take froward and elaborate on in the short term. We’ll put the other stories aside for now.

Phase 3 – Acceptance Criteria

Now that we’ve go the likely candidate stories, let’s figure out what it would mean for the story to fulfil the needs of the user. This is stuff like “I typed the term ‘AA Battery’ into the Search box, then clicked Search. The results would come up in alphabetical order based upon the product name”. There might be several of these Acceptance Criteria, which are sometimes known as “Conditions of Satisfaction”

Phases 4 and 5 – Prototyping and Front End

Even if we have a User Story or three, and some Acceptance Criteria. In order to actually work on it, the team will often need to know more. In Extreme Programming (XP), the information would be communicated with face to face conversations with the customer at the time of implementation. In these guidelines, I show some other inputs that might help the team to implement the stories effectively. In this case, prototyping was used to help to add understanding in the team about how the stories would work when implemented. The User Centred Designer would also work with the Front End Developer who would produce front end code that would be passed to the the developers.

Phase 6 – Bundling

This is simply, making sure that everything is together and at the point of readiness. We don’t want to start developing the stories, only to find out that some of the info that is needed, hasn’t been done.

Download and related post.


pdficon_small Product Backlog Creation guidelines (288kb)

Related post

Creating a Product Backlog: Story Mapping. I also have a post about Story Mapping, a Product Backlog technique that I think is useful. It also talks more about the concept of having enough detail to work from for upcoming work, but keeping things at a high level for work that won’t happen for a while.

Introducing: Agile Business Analysis course.

Agile Business Analysis Training Course samples

A service that I offer is training courses for people entering into or who have started to be involved in agile projects. I know when I first started on an agile team, going on a training course really helped to put all the pieces together, in a way that reading books and articles couldn’t quite match.

Agile Business Analysis course

I have developed a course called  Agile Business Analysis. The 2 day course covers the principles underpinning agile development, and how as a business analyst you can be involved in agile projects in the following areas:

  • establishing project vision and needs
  • understanding your users
  • User stories, story mapping and Product Backlogs
  • Planning and Estimation
  • quality and project governance
  • solving BA challenges
  • continuous improvement

Practical activities are used throughout the course; you will envision a product, and progress through different approaches to build a shared understanding of that product vision. As an advocate of agile/lean User Experience techniques, I include a good amount of content from that discipline.

This course can be run in-house, and it is also run publicly at various times during the year.

This course should also be eligible to be counted towards continuing education/professional development units requirements of various professional qualifications. I can provide you a certificate of attendance, should you need one.

Would you like to know more?

To find out when the next public course will be held, or to enquire about an in-house course, please contact me