Breaking into a Sprint
I just stepped through a session planning out the next couple of iterations on a product halo with a colleague of mine. The process we have taken to using is quite cool. I don’t proclaim it to be unique in any sense of the word, but definitely something I’m liking the feel of, and one I could see really developing and growing with the organization.
I started by writing out a set of bullet points, broken in to feature groups on the white board. This was our baseline. We talked through each point, made some revisions, removed some, added some others, and proceeded forward. This really allowed us to reset, and get in to what it was we were trying to accomplish.
We then proceeded to prioritize each bullet point. Since we have a lack of customer data, and some things are just obvious (especially when dealing with halo items), it was pretty easy to go through and assign low / med / high or 1 / 2 / 3 to each bullet we had written up there.
After the bullets were all prioritized, we then assigned gross hourly estimates to them - nothing under 2 hours allowed. Since the bullets weren’t full requirements, this kept things padded to a reasonable amount, allowing us to continue marching towards to goal (yes, details on what exactly what is forthcoming).
We then decided, right or wrong, that since these are halo items and not product “features” in the true definition of the word, we didn’t need to rev the version number at all, really. So it was just a matter of adding up all the gross estimates and then identifying sprint length and doing some simple division.
So, we landed on each sprint being 10 days in length for the project. With all the tasks grossly estimated, this ended up being something like 9 sprints total. We backlogged a few things, but couldn’t really get that gross-level estimate to budget too far, so we stuck with it.
My colleague now has the lucky job of fleshing out those bullets in VersionOne and assigning them to the correct sprints. And then of course, gathering up all of the materials that do already exist and attaching them to the right items, and then proceeding to execute on some key market research tasks that were identified.
Yeah, I guess I’ll help out at some point.
So, what did we end-up with? Well, a pretty common thing - a set of requirements, associated to a release project and sprints in our requirements / product management tool (VersionOne). “Big deal” you say? Well, it’s important to recognize that when you have a crap load of things to do (especially halo items, which can be convoluted), using a framework / brief / flexible process that helps get all that stuff that’s currently up in your head down on paper and in front of others, can be a huge weight off your shoulders.
Keep tweaking, keeping writing things down - but when you find you have it all up in your head, take a step back, get some people in the same room as you and start to write out bullet points and take it from there. Worst case you end-up with an empty head and an eased mind. Best case, you have developed a quick and dirty roadmap for the next several weeks that can be iterated on.
