Agile planning has always been a hit-and-miss affair. At one end of the scale is the soul-crushing, multiple day workshops whose output is a list of hundreds of detailed features, many of which will never see the light of day. At the other end is the continual insertion of random demands into the product backlog, with the team constantly on the defensive, never knowing what is coming next and forever switching context. We estimate as a group using story points and then we carefully track velocity, burn-up, burn-down, and use this to predict delivery timescales or commit ourselves to near-term deadlines. So with all this rigour and discipline, surely your team is a highly-energised unit, delivering quality software in a regular cadence, free from the thrashing, context-switching, pressure and uncertainty that would suggest “bad” planning, right? Or maybe not. Maybe features aren’t the point of delivery after all. Maybe there are other kinds of work that we could recognise, schedule and track as first class citizens. Maybe this could take some of the uncertainty out of the delivery process, and give us back our sanity. Maybe.