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.
tastapod
jmatsu
tsukushi
pulse1923
ogiwarat
jpt_corp_official
yatasunshine
akitotsukahara
lnit
murajun1978
iimokoy
kin29
ivargrimstad
holman
phodgson
colly
jasonvnalue
kevinliebholz
sugarenia
eileencodes
paulrobertlloyd
robhawkes
malarkey
caitiem20