Maintaining visibility and clarifying things as and when they arise

How often have you walked out of a meeting wishing attendees has at least: read the previous minutes, attended to their actions, not waited before they let you know about a problem. Do you wish people did not think you were a mind reader.




Creating your Initial or First product backlog (Backlog Items)

Creating the Backlog Items.

This builds on the previous article you can find here
In this session we will

  1. For each user
    • review the goals and needs we defined in the previous session
    • expand these goals and Identify the features that support them, all the time focusing on business value.

    For this we need the same team we have in the previous stage, but expanded in a few areas.

Creating your Initial or First product backlog (Find the Users)

Easy, write down a list of individual features and order them, job done? If only that was the case!

A product backlog is not simply all the product features, it is all the work needed to build and deliver the product. This includes all features, functions, enhancements, and fixes, all that boring engineering work, infrastructure commissioning, documentation and loads more. It is also a planning tool, letting us know what is most important to the business an gives us some indication, along with velocity, when the project is expected to complete.

Will the 'Backlog Review' be the next Scrum event?

Have a look at the scrum guide and you will see that the team is expected to spent around 10% of their time reviewing the backlog. With all the will in the work, this is not easy to achieve. Even a highly disciplined team will find this difficult, especially when trying to spread the time across the iteration. Sure it is a little easier near the tail end of the iteration, but what this means is that there is a lot of work on the backlog very close to the start of the new iteration.

Printed story cards for your Scrum board

I am a firm believer in a big tactile visible physical radiator board. You can simply not beat it for something that serves as a focus for the team and help them maintain scrum practices. This can sometimes be a problem when the projects you are working on have outgrown hand-written index cards but are not yet big enough for a formal tool, or they simply need a little more formal retention. (read governance here).

Dealing with 'Late arriving' User Stories

An issue that often arises during the sprint retrospective (the most important Scrum event), for new teams is the fact that not enough is known about very new high priority stories to be able to estimate them. This leads to wildly varying estimations, arguments about how or what should be done, committed work not being completed during the iteration and a whole host more problems. It also make the negotiation between the Product owner and the team very 'interesting' during the planning session.

Reasons for these late arrivals could be:

On what day should your iteration start and end?

Surely start on a Monday and end on a Friday. Nope, unfortunately it is not as easy as that!
Never end on a Friday is a good maxim, well not unless it takes all weekend to deploy. Why not end on a Friday then it give us the entire weekend as a safety net if things go wrong?

Free practical Agile Scrum tool now available!

A free, simple and easy to use Scrum tool that is specifically aimed a teams new to scrum that don't want to battle with learning a complicated tool while busy learning scrum. The tool (I hope) helps re-enforce Scrum principles, makes sure everybody knows what is happening and who is looking after it.
Featured on http://freescrum.com/category/tools/

Free Scrum Software coming soon

Coming soon to the resource section. Practical Agile Scrum Tool a free, simple and easy to use Scrum tool that will help you manage Projects, Iterations, Stories, Story Tasks and Story Comments.

Potentially releasable does NOT mean released!

Any Scrum teams primary objective is to deliver potentially releasable software at regular intervals. The key here is potentially releasable, NOT released. A release costs time and costs money. If we don’t need to do it, then we shouldn’t. Not needn’t, shouldn’t! Conversely, when we need to release, we should be able to.

Pages

Subscribe to practical agile tools, tips, tricks & useful resources RSS