Posts Tagged Iteration Planning
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).
Feature Burnup Charts are on the Cards
Posted by nthorpe in Telstra Contact Solutions on April 17, 2013
When agile is working at scale, with multiple teams, there is usually a need to see progress through the work at different “zoom-levels”.
Most familiar is the story zoom-level: How are the stories progressing? Are they blocked? Why? How is the iteration progressing? Team boards, and team level hacks, help us to see these things change, and to understand how to improve.
At a higher zoom-level, the visibility needed is: How are multiple teams progressing through the larger pieces of work (we’ll call them features) which the stories are part of. So what we need to see is: When are they likely to finish this feature? What’s at risk? What’s blocking the team? Does the team need help?
This level of information is often represented on a program wall, which is a bit like a “zoomed-out” version of a team wall, showing the backlog of features to be delivered, cycle time across the whole program, and so on.
Here’s an example of a program wall. Each team is represented by a horizontal row and the columns are the iterations in which the teams expect each feature to finish.
The program wall shows all the features in progress.
The detail of how these features are tracking is found on the individual teams walls. But one team found a way to clearly summarise their progress on this wall too. They decided to stick burnups onto the front of each feature card. (A burnup is one of the most eloquent of board hacks as it provides a single view of scope and velocity, as both change).
Burnups on each feature card show the team’s progress through that feature, as well as changes in scope.
You can see it a little better below:
So now, when you’re standing at the feature wall you can see the burnup for that feature, right on the front of the feature card without having to go and find the team wall. In this example, the feature is in the Iteration 12 column, but the burnup tells me it’s more likely to finish in the 14th iteration unless something changes – I smell risk! You can get a very rich sense of what’s going on, at a glance.
Spotted: Telstra Contact Solutions
What we said vs. what we did
Posted by fe in Lonely Planet, Lonely Planet SPP Dev Team on April 14, 2012
Are the stories that are talked about in planning always the ones that actually get played during a sprint? In an ideal world they are, but seldom does a sprint run according to the ideal.
This team was getting a lot of work done, but still seemed to have cards left over at the end of a sprint. Were the cards taking longer than expected? Were additional cards being added? No one could quite be sure.
One of the team members came up with a solution. After the team had agreed the stories that would be played for the upcoming sprint, he took a photo of the cards. This provided a visual record of what the team had agreed would be done.
It was stuck up next to the backlog and as cards were completed they were ticked off on the photo. At the end of the sprint it was easy to see what had got done, or not, out of the planned cards, and which new cards had been added into the sprint.
This is a great example of a team member taking matters into their own hands and using their own visual language (photographs) to come up with a fresh take on planning.
Spotted: SPP development team
Release Radar helps you see through the fog
Posted by nthorpe in If we tell you we'll have to kill you on February 10, 2012
A common or garden Agile board is good for a view of the iteration you’re in, and perhaps a little further out. But what about when you need to see even further? Agile teams often face the problem of “boiling priorities”. Priority changing on big pieces of work daily. You start to work on them, and then you hear they have been de-prioritised. It’s hard to know what you should be working on. The team can churn through a lot of brain cycles thinking about pieces of work which may or may not eventuate. This can be stressful.
Sometimes we need to be vaguely aware of pieces of work which are “out there” in the future, whilst still keeping our focus squarely on what we know is coming next. Different roles in the team, too, have different time horizons they need to care about. For Project Managers, or Business Analysts who need to organise and run inception activity, it’s good practice to keep an eye on what’s coming down the pipe. For developers, it’s often: “Meh. Just tell me what I need to do next.”
Daniel Aragao showed us a great way to deal with frothing priorities – the release radar.
Here he has trained his radar across the portfolio:
– each concentric circle represents time (12,9,6,3,1 and .5 month). Items far out on the radar are distant in time, items nearer the centre are closer in time
– each slice is a project, identified by a post-it on the outer rim
– resources working on the project are also on the outer rim – these will be avatars in the future
– each post-it represents a task, module, something that is big enough to be picked up by the radar
– post-its will be colour-coded to show the size of each task. T-Shirt sizes (S-green,M-yellow,L-orange,XL-red)
– IT, Ops and Business get together every 2 weeks to update the Radar and discuss associated risks
On our team, we took the idea and adapted it to our needs. Our radar simply tracks pieces of work as they orbit our world, and then come in to land.
The purpose was to be able to provide steady priorities to the team (they only need to look at the innermost ring), to help our BA structure her work with stakeholders on preparing epics, and to get a view of the whole pipeline if we needed it. We keep it on the back of the iteration board, and a subset of the team meet once a fortnight to update it. It tells us what we need to actively think about, and what we can ignore.
The quadrants relate to stakeholders.
Spotted: Daniel Aragao of Thoughtworks shared this idea.
Agile Board Hacks 