Scaling Scrum (3-4 teams) (Part 2)

This builds on Scaling Scrum (3-4 teams) (Part 1) Part 1 looked at the situation where there were multiple teams working on a single product. This will look at instances where there are multiple teams working on different projects/products in the same organisation. i.e. each team has a different backlog. Remember the rule though 1 product = 1 backlog!
What we are going to do here is to make sure that separate products/projects are in sync with each other and dependencies are made visible and met with minimal delay.

Some examples may be:

Claiming Points (It's not Done until it's Done)

I recently came across a Scrum team that was working in what I felt was a bizarre manner. A manner that was undermining their credibility. The business was losing confidence in them, by association the other teams and Scrum in general.

Blog tags: 

Scaling Scrum (3-4 teams) (Part 1)

Scaling Scrum is easy, have a look at the Scrum guide at http://www.scrumguides.org . You have a number of teams that each operate as normal and a member from each of the team attends an additional daily scrum. Yes, it all makes sense, but it is a lot easier to say than do, even on a small scale. There are a few practical things that newer teams and organisations need to think about and do other things will descend into a state of anarchy.

By and large there are two sets of circumstances where you need to scale.

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

Blog tags: 

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 https://github.com/paul-lab/practical-agile to find it.
It is obviously still available as an archive here.

Pages

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