The easy way to write acceptance criteria

We all know that a user story should not aim to capture all the detail about a requirement or business need. It is more of a promise that a conversation will take place, the options explored and some work will be done that will deliver that business value.
One of the key things to make sure of, when writing user stories, is to have a clear view as to when a piece of work is completed. The normal way of doing this is to document a set of acceptance criteria against a user story. What we don't want though is to write a 20 page requirements document as acceptance criteria.

Story Kick-off

Story Kick-off: Why on earth would we need one of these? Well think about it for a while, you have a project kick-off, an iteration kick-off. Any significant piece of work has a kick-off before work start, and for a very good reason. We need to make sure that there is a common understanding on what it is we are going to do, what we are going to deliver and how we are going to deliver it.

Try this as a standard agenda to a story kick-off and see how it immediately improves things

Story Kick-off

Daily Stand-up Agenda

Why would we ever need one of these? Well put simply it is to instil and ensure discipline. It is to make sure that the team give the update they need to without getting distracted and at the same time making sure that any stolen time is recorded.
It is there to make sure that the meeting is productive and that best us of the teams time is made.
Daily Stand-up Agenda

Terminating a sprint

Terminating a sprint is essentially throwing away unaccepted work in the sprint the sprint and starting a new sprint instead. This is not a decision that should be taken lightly as it costs. It costs time, it costs effort and it costs money. It will also ruffle more than a few feathers. It is however cheaper that continuing with a sprint that is invalid, will provide no business benefit and not be delivered.

Some of the things the free Practical Agile scrum tool can do

Use Epics to group product themes or feature sets (You can order these independently from the Backlog)
Break epics down into sub-epics or stories into tasks
Hovering over a collapsed epic will expand it.
Assign categories to projects to group them on the project list.
Use comments against the Project to record key project information or decisions.
Use comments against an Iteration to keep a log of your standups and retrospectives
Select a card, hold the left button down and use 'page-up/down' or the up/down keys to move cards large distances.

Practical Agile Free scrum tool usability blitz

I am busy with a bug and usability blitz. (check the release notes!)
If you have things that have been irritating you, or things that could simply work a little better or simpler, then please let me know via the contact page. I am also thinking about dropping the html formatting in favour of markdown, what is the general view out there?. Keep an eye on the Download page for a One Stop windows install, or on github.

Practical agile Free Scrum Tool now on Github

The Practical agile Free Scrum Tool is now on Github.
Practical agile Free Scrum Tool is now on Github. browse to to find it.
It is obviously still available as an archive here.

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.


Subscribe to RSS