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.


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 https://github.com/paul-lab/practical-agile 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.

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).


Subscribe to practicalagile.co.uk RSS