Managing Iterative Delivery Flashcards
Don’t push everything into stories
Don’t create fake stories that are about the developers needs. Set aside a dedicated time for internal tasks, dont put these on the backlog.
Budget instead of estimate
Instead of estimating, try to start with a budget for a bigger piece of work, in terms of both operational costs and time. This budget can then become a design
constraint for the delivery team, similar to scalability or performance.
Essentially, rather than asking ‘how long will it take?’, ask ‘when do you need this by?’ and ‘how much can you afford to pay for it?’ The delivery team then needs to come up with a solution to fit these constraints.
When there is no good value model, try the following two approaches:
- Ask about extremes
- Budget incrementally
Story sizing is useful for only one purpose:
Deciding whether a story is too big to implement or
small enough to get fast feedback. Almost any story sizing heuristic can help teams make these decisions. But that’s it – story sizes aren’t really useful for anything else.
Avoid using numeric story sizes
When you are comparing stories, try to avoid using numerical sizes. Choose a different sizing mechanism that allows you to make the distinction between
‘too big’ and ‘just right’.
One good idea is to select several representative stories to serve as a reference, and compare any new stories to them. Again, avoid numerical labels. For example, group stories into small, big and unknown.
Estimate capacity based on rolling number of
stories
Avoid using the number of stories for long-term estimates. The average time it takes for a story to go through the pipeline is a far better measurement for longterm planning than any kind of story size.
Estimate capacity based on analysis time
time-box the iteration refinement and planning
session and only take into the iteration what you were able to agree on.
Using analysis time as an indicator of complexity is an alternative to measuring story size or counting stories, so it does not require any kind of numeric accuracy. It is also significantly faster than other capacity planning methods. The delivery team plans capacity at the same time as analysing stories, so the time used on guessing numbers can be used for more productive work.
Estimating capacity based on analysis time works well in contexts where the critical complexity of delivery is in understanding the business domain. If the majority of your stories are easy to understand from the business perspective, but the tricky part is actually making it work technically or fitting it into an existing legacy infrastructure, analysis time isn’t a good indicator. That’s why this approach won’t work well in contexts where the critical complexity is technical.
Pick impacts instead of prioritising stories
As an alternative to story prioritisation, try to pick the most important impacts on customers. Impacts are much easier to discuss and compare than stories, as explained in the section Describe a behaviour change. Combine this with the idea of budgeting instead of estimating and you can get a set of nice constraints
for the delivery team.
Never say ‘no’ – say ‘not now’
The key advantage of this approach is reducing interruptions while avoiding political conflict. Saying ‘no’ might be politically inappropriate, but asking people to accept ‘not now’ is perfectly fine. Delivery team members will be
able to focus on achieving big business impacts and not waste time on ideas anyone from the business can think of.
If you are working in a situation where it’s impossible to refuse requests from senior management, first try to get key stakeholders to prioritise business impacts instead of stories.When someone proposes a change, ask them to review whether the proposal fits the current business objective. If not, offer to stop working on the current objective and prioritise some other impact, or to
postpone the proposed change for later. Most of the time, the person asking to change the plan will reconsider.
Split UX improvements from consistency
work
Because of these two different contexts, integrating UX work into regular user story delivery cycles often creates half-baked solutions. For some tasks, designers do not have time to properly investigate and test solutions before developers start implementation work. For other tasks, designers waste time doing obvious stuff, which developers and testers could do on their own with a bit of knowledge transfer.
One solution that works well in many contexts is to divide UX work into ongoing consistency and significant improvements, and manage the two types of work differently.
For ongoing consistency, specialists need to teach
developers and testers how to spot and resolve common issues.
For larger improvements, designers and developers need to work together in a time box on building prototypes to discover what they actually want to deliver later.
Get end-users to opt in to large user interface
changes
Instead of one major upgrade to all your assets, split work into smaller chunks and invite users to opt in to the new interface. Run the old and new versions in parallel, incrementally building up the coverage of the new version.
When endusers choose to use the new version, they will be prepared for some temporary inconsistencies and won’t mind if one page looks different to the others. New users won’t necessarily know about such changes until the whole thing is
finished, so there will be no negative impact on the sales funnels or churn.
Once the entire redesign is complete, you can make the new version the default
and slowly phase out the old version.
Check outcomes with real users
Even planning to check the outcome after delivering a story makes teams write better stories. It has the same effect as test-driven development does on code. It provides focus and clarity, and leads to better solutions. It stops teams from over-engineering the software
Throw stories away after they are delivered
Reason is that in order to understand the current situation, someone has to discover all relevant stories, put them in reverse chronological order, find out about any potential conflicts and changes, and then come up
with a complete picture.
