Sprint I’ve been on a few Scrum teams now, the latest with my current Intuit Hosting Engineering (HE) position. HE is doing Scrum well, implementing almost all of it as far as I can tell. I recently took the training to be a certified Scrum Product Owner – one of the three primary Scrum roles. It seems like this is what was missing from the Innovation Lab (iLab) processes we used – the “what came next” part that was always a challenge for us.

In the iLab, we had an unmatched process for discovering innovative solutions for tough problems, and getting quickly to the minimum viable feature set. What was tough was then transitioning that to a business unit for development and launch. Scrum takes care of that part of the process.

Diminishing detail What we needed was a feature set that was described in terms of User Stories, detailed deeply enough for a development team to estimate in terms of relative development time (story points). The User Stories would be more than just the minimum viable, getting us over the hump of disbelief on the part of the business – disbelief that the product had enough features. The “minimum viable” would simply be the highest priority user stories, and the entire set would be in the “backlog” – all of the known user stories in diminishing detail.

The cost/time of development would be established if you already had a Scrum team, but it only takes about three Sprints – 1 to 4 weeks – to establish a baseline “velocity” for a new team. Velocity is a simple measure that indicates how many story points that a team can accomplish in a given sprint.

Trifecta When a team follows Scrum, they can become hyper-productive: teams that quadruple their velocity compared to their first sprint. There’s apparently two simple things that get a team to this measure – a backlog that has very well-defined user stories and an automated build that includes automated testing.

I think there’s a trifecta here that, when combined, would be a simple but effective way to make a successful idea into a successful business: front end innovation (iLab style), with lean startup-mindset prioritizing of user stories, developed by a Scrum team.

One Response to “Scrum”

  • Harlan says:

    Another approach to Agile that I think would really have benefited the lab is the Lean UX approach championed by Jeff Gothelf. It’s a combination of some of the collaborative principles of UCD with the efficiencies of Agile. Jeff’s way of thinking about it is one of the only ways of integrating the waterfall-style methods of the traditional design process with the sprint-based approach of Agile, although it still has difficulty with upfront investigatory research – but in the project-based iLab way of doing things, that would have been less of a problem, I think. Check it out…

    http://uxdesign.smashingmagazine.com/2011/03/07/lean-ux-getting-out-of-the-deliverables-business/

Leave a Reply