Agile – Page 2 – View from the Potting Shed

How to create new MoSCoW prioritisation statuses in Jira

St Basil's Cathedral, Moscow — Visiting St Basil’s cathedral was a must when I visited Moscow in 1988

A few months ago, my team at work considered using DSDM’s MoSCoW prioritsation technique for our project’s user stories in Jira.

After a little pondering, this morning I worked out how to do this in our cloud-hosted Jira. This short post shows you how.

Retrospective idea: Sailboat

Blue and white sailboat on ocean during daytime — Photo by Evan Smogor on Unsplash

The sailboat retrospective is a model that I especially like to use at the end of significant chunks of work, like a release or the end of an epic or the end of a project. But it could be used at any time, especially if there is a need to better understand project objectives, risks, hindrances and helpers.

I like to use this model for post release retrospectives because it helps the team to focus on lessons learned around unexpected risks, the things that slowed the team down and celebrate the things had really helped us.

Retrospective idea: one-word

A simple retrospective exercise I like to use is the ‘one-word retrospective’ found in Getting Value out of Agile Retrospectives by Luis Gonçalves and Ben Linders. This exercise is particularly useful for helping teams deal with their feelings.

Simply ask every team member to summarize in one word how they felt about the last sprint.

Retrospective idea: starfish

Just as a workman wouldn’t rely on the same tool for every job (unless they have some kind of massive Swiss Army tool), it can be useful for Scrum teams to have a few different retrospective models to draw on. Different approaches help teams to see things from different perspectives.

The starfish retrospective is an extension of the typical three-question retrospective of what went well? what didn’t go well? what could be improved? By asking similar but different questions it can help a team appreciate the practices that are going well as well as consider new ideas. I know scrum masters for whom this is their default retrospective pattern.

The importance of small user stories

Battleship beneath a grey cloudy sky — “Grey and black boat under grey clouds” by Will Esayenko on Unsplash

I’ve been thinking a lot recently about the size of user stories in agile projects. The idea that I’ve been reflecting on is what if teams only worked with small, similarly-sized pieces of work, rather than exponentially larger blocks of work?

In theory, small user stories should be more predictable, should include less risk, less uncertainty and less complexity. They should, therefore, take less time to complete than larger user stories… you would think! Or as Mike Cohn put it in Agile Estimating and Planning (Prentice Hall, 2006), “small stories keep work flowing”.