A simple visualisation technique to manage multiple releases in a sprint.

One of the teams I work in is a new product development team. Up until recently we have been working on a minimum viable product feature set. We work in 2 week sprints and at the end of each sprint we did a demo and deployment to a demo environment. We got very used to having this release bus style process and planned our sprints accordingly, what can we release in 2 weeks.

However, recently we went 'live' to a limited Beta release and the dynamic changed. We had our minimum feature set being used by customers, and they were giving us daily feedback. There were features we could get them in 2 days development but hadnt really visualised our information so that we could see the Tree's for the forest.

In an hours discussion with my accomplice Yoram, we came up with a colourful, yet simple way of visualising all the little featuresets and prioritising them. People do variations of this, hell they've probably already done what we do, but I kinda like itso I thought I'd share how we did it.

Caveat: We control our own releases, its a greenfield codebase and we have high levels of automation (in both our release and test processes)

Themed ‘releases’ within sprints;
We continue to run sprints and do commitments to that sprint, but within that framework have themed ‘releases’. The ‘team’ commits to a set of stories and aim to release whenever enough stories are done to warrant a release. This could mean 1 or many releases in a sprint.

  • In planning we group the cards by the ‘theme’, this could be ‘pagination’ and that theme could include many stories across many disciplines, or even 1 story.
  • Initially the release would also carry with it some premium of ‘technical’ work to automate the release process, but this would decline rapidly as we did more releases.
  • We group the minimum cards required to warrant a release together (i.e. Pagination). This would include any stories that we either need, or would be affected by the development of this feature set (tablet, infrastructure or webapp)
  • In JIRA we create a specific tag (or version) for this release named “Pagination”;
  1. On our board, all cards for that ‘release’ get a coloured sticker.
  2. We focus our attention on the ‘release’ goal at stand ups as primary, with sprint commitment as secondary (but still Important)
  3. If someone can’t work on something in the release goal, they move to the next priority card.
  4. We would group cards by release ‘colour’ even technical stories to allow us to better see progress and dependencies towards the goal.
  5. We would need to do something clever in the build to allow us to manage this.
  • We than focus our immediate goal as being that release and prioritise those cards over any other.
  • The team than commit to cards together as a total for a sprint
  • We use sprint boundaries to manage Retro’s. Demo’s and planning, as well as Inter Sprint days.

What changes:
  • How we plan
  • How we layout the cards on the board – grouped by releases and than priorities within that
  • The team commits to releases as a focus, rather than points
  • Releases whenever we have a feature to push out

Disadvantages
  • More complicated planning
  • Some admin overhead
  • marketing overhead

Advantages
  • Team commitment - its always exciting to release your code and have your customers provide rapid feedback
  • Release focused
  • We get stuff out as soon as it is ready


This shows the 'story' cards on the board. Details have been smushed but the 'dots' are clearly visible. The cards are grouped by colour, when all the cards of that colour are across the board, the feature is ready for release.



This shows our little 'feature priority/name' key. This is off to the right of the board. This means at stand up we focus on the highest priority feature and can clearly see progress of it on the board by the state of the cards with that coloured dot.



This is our 'big picture' release board. We have our "epics/featuresets' here with when we are proposing to do them. These are now colour coded (by the same dots) so we can quickly tie them to the stories on the 'sprint' board.

Comments

Post a Comment

Popular posts from this blog

Using an agile storyboard as a scale of certainty

Image
As per my previous post, In my current team we have started using a 'Just in Time' (see how I feel weird about saying Kanban, not sure why yet) approach to doing various activities around development. Mostly this is around planning, but in that sense, we are also doing as much Just inTime as possible in giving an estimate. Scene setting We are a team that does 2 week sprints, but we also don't do a major release at the end of each sprint. We tend to wait for 5 sprints to pass before we do releases, there are a number of organisational reasons for that, but suffice to say, thats the way we do it around these parts. Our story wall (in ugly table form) The table below is a basic representation of our Story wall. As you can see, for the story wall, we deliberately do not just focus on the current 2 week sprint. We also have columns heading beyond the current sprint to encapsulate the entire release timeline (in this case the team have already completed two sprints so their are
Read more

A survey on release processes with organisations that 'sef-identify' as folowing agile practises.

Image
Earlier this year I ran a survey around ‘release processes’ specifically with companies that follow agile practices. I promised that I would publish the results and apologies for the delay, I have collated the responses below. Thanks to everyone that participated, really appreciate your time and energy. At iflix we're always looking to improve our release processes so it was really great to get so many good responses. We learnt we're not that far apart from our peers out there. We've got a lot to learn of course, some of that comes from hearing from others and some from the mistakes we make. The trick is to make your mistakes small ones and learn fast with minimal disruption to your customers. This survey was run at least 5 months ago, so it’s a snapshot in time.  Most places I have worked change their processes (inspect and adapt!). I've reproduced the responses in their entirety, so it is a bit of a long read. I’ve anonymised the responses somewhat, retaining
Read more

Mission Orders, 6 military principles that can work for agile teams

Yesterday, I was watching a documentary on the "Battle of the bulge" A famous battle in World war 2. The docu makers were investigating German tactics during the battle. Specifically, tactics which had worked so well early in the war, over extended periods of time, towards the end of the war, fell apart after 3-5 days. Early in the war, German officers had Mission Command, that is, Hitler and high command had high trust in their teams. As the war went on, and things started to go wrong, mission command was gradually eroded as trust fell (especially when his officers tried to kill him). Mission command basically means, set the goal, let the teams be responsible for how they are carried out. Training is centred around this, discipline and training carry you through the unexpected, as long as you know the end goal. Effectively, the German high command no longer trusted the lower ranks, and only gave them enough information, goals etc for the immediate goals and set them
Read more