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

Experience report: Building an offshore agile team in India - The Australian perspective - Part 1

Experience report: Offshore agile teams – An Australian in India’s perspective Offshoring software development, in this case, using agile as a software development methodology contains many opportunities to learn. These kinds of teams have specialised requirements both in the technical realm as well as social expectations on the individuals hired. A lot of organisations have tried, and failed in a lot of cases, to set up independent agile teams in India . With the right approaches and expectations set, Aconex has shown that it is possible to successfully set up agile offshore operations as we did. To get your offshore program on a sustainable footing you’ve got to understand the market and be prepared to be responsive to local conditions. What sort of people are/were we looking for? A simple explanation would be, agile software engineers and product people with a desire to work in self managed, highly collaborative teams. We use the terms ‘passionate, self-starter, indep
Read more

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

Building agile teams in India: Part 3 - challenges at the hiring stage (especially for a fresh face in the market)

Part 3: Constraints/Challenges of building a ‘boutique’ agile team in Bangalore/India (especially if you’re an unknown in the market) Low brand recognition In India, brand is seen as really important for a lot of candidates even in 'considering' an organisation. Family recognition of the organisation is seen as very important to candidates, acceptance of the organisation by candidates parents is often a key factor. There is also evidence that candidates enhance matrimonial chances by joining a known brand, I've even had conversations that dowry can be increased dependent on the name of the company.  All of this leads to an uphill challenge for smaller organisations, however: The candidates that do join you are joining because you've sold the company culture and challenge well, which increases loyalty/retention. Also, working on brand building is shown to pay off over time, hence partly an answer to the question of “Are you ready for this to take ‘x’ ye
Read more