Posts Tagged Planning
A Most Excellent Roadmap for your Adventure
Posted by nthorpe in Uncategorized on April 14, 2015
Like they say at UK.gov, ” if you’re gonna build a time machine into a car, why not do it with some style?”
This post is so perfect, we just had to link to it. Read and enjoy.
http://www.mindtheproduct.com/2014/07/experiments-roadmapping-gov-uk/
Epic status
Greater visibility to stakeholders: it can be an ongoing battle. Even when they’re au fait with the vagaries of ‘when we finish this we’ll start on the next priority feature’, keeping them up to date can be tricky. And what about the “zoom level”? Stakeholders want to see the big picture (roadmap) and the detailed planning.
We see teams tackle it many different ways, and often end up with a separate backlog of epics, or a feature roadmap, or future sprints mapped out across the wall. Craig of Better Projects sent us this hack by colleague Ben Birch at Aconex. It gives tight focus to the team’s work, without the need for a separate wall for a roadmap.
They simply added a lane around the outside of the sprint board, which indicates the flow of epics through their development lifecycle – from the backlog, through planning, development and release. Epics travel across the top of the board – the further they go, the nearer they are to completion.
Epics start their journey in the backlog. The priorities are fairly fluid here, as priorities change and new features are added. Realistically, anything not in the top two or three epics is aspirational. And with multiple stakeholders, this is where the horse-trading of priorities can take place. These epics haven’t yet had much work done on them — and commonly haven’t been broken down into stories.
An epic in the planning stage is in the process of being broken into stories and analysed through more carefully. The product owner is working on them, perhaps there UX investigation going on, or there may be some spikes in play.
An epic moves into in progress when work starts on the first story card.
Story cards for the epic are added to the stories backlog on the main, internal area of the board — and colour coded to match the epics in progress.
In the picture we can see one green epic nearing completion, with another blue epic just beginning. It’s worth noting that all the stories for an epic are added here, there is no separate backlog for stories. When necessary, the team will draw a line through the story backlog to indicate where they plan to get to within the current sprint (not shown in this picture).
A wall with a view
Posted by fe in If we tell you we'll have to kill you on June 13, 2013
As we’ve mentioned before, sometimes you just have to work with the reality that you are not allowed to stick anything on the walls – especially when your walls are the glass of an office building.
A team I’ve been working with recently knew that they needed to come up with a solution to comply and respect their building policy – however the only space was the glass. A policy common in many buildings. However they didn’t let that hold them back! After a couple of weeks they had a feel for how much space they were using, so they designed their own walls. As well as being portable, they also had to let light through so that they weren’t blocking out the natural light. Their innovative solution was clear perspex agile boards – and they are one of the slickest solutions that I’ve seen.
Ironically, they are almost too good. From a distance the perspex agile boards blend into the building windows. Many people do a double take when they realise they’re not on the windows at all!
Spotted: If we tell you we’ll have to kill you
Dependency mapping
Posted by fe in Telstra Contact Solutions on April 20, 2013
An Agile world without dependencies would be a wonderful place. Each piece of work could be executed independently of any other, in any order. In a perfect world it all works out just like this. 😛
But much as we would like it to be, it’s not always like that. Dependencies are real. For example: hardware might be required to provide the value the end-customer wants. And until it’s in place – either for development, or testing, or production – you just can’t create that value. Dependencies are especially common in large, distributed pieces of work where one team will depend on the work of another. Ignore them at your peril.
The board below is one of those situations. A large program of work spread across multiple teams, with dependencies between teams. Caleche Watson, the project manager on this team has mapped out the dependency using a piece of string, so its clear where it lies.
A piece of string shows the dependency between two pieces of work.
Teams which depend on each other need to talk a lot to keep in sync and ensure the best outcome overall. This piece of string makes obvious a conversation that needs to happen at their regular joint stand up. As Caleche said:
“At the end of the piece of string is a conversation”.
Spotted: Telstra Contact Solutions
Agile Board Hacks 