Initial Feature Planning and Level of Finish

  |   Agile, Blog   |   No comment
A question from a friend of mine in the Seattle area, working in a hardware company on one of the software teams that supports the software, wrote about story size splitting and Agile Principle number 10:
My question is about initial feature planning and level of finish.Example: I’m making the first implementation of a wireless key fob for my car. Previously it was just a metal key. My main feature is lock and unlock doors. Does it lock/unlock only driver side door or all doors or both? Does it need to have panic mode? Trunk opening (assuming there is an electric trunk opener), etc.

I think you get the idea. Where do you say, “this must be in the implementation” and where do you say, “this can wait”? I’m looking for an answer that relates back to the customer of course. I would assume in the above example that delivering less than a capability to lock/unlock driver side or all doors and a panic mode would be not enough because of public expectation?

I’m wondering how to reconcile this with the principle of maximizing the amount of work not done?

My reply:
If the team can get a small, working, tested, elegant feature out the door each week, it’s no problem for me as a product owner to ask for just the driver’s side unlock. Then use it at the demo, then ask for the panic button. Then use both at the next demo, as it’s only been two weeks.
If the team is slower, then my first priority is to give them easy wins to pump up their morale which in turn makes them more likely to increase their velocity of Done Tested Releasable features. So I’d split it even smaller than Driver’s side door unlock only: maybe a key with a compartment in the fob that can hold a battery and circuit board, but they haven’t had to develop that yet. Then the next sprint, after I’ve seen them slide in and out a plastic card to mimic a battery and circuit board, I’d say now it needs to be a circuit board in there, with a battery, and button, and a red light that blinks when you push the button.
If the team is not able to get any of those Done, Tested, Releasable at sprint end, I’d split it further, ask their Scrum Master for the list of impediments from the team to getting more done with quality, and set myself to removing all the impediments in priority order. After removing the impediments, if the team still can’t get me done and tested features in a single sprint, I’d stop paying them and look for a more capable team to fund.
Agile Principle Number 10, Maximizing the Amount of Work Not Done, is about cutting the 80% of the backlog that, statistically, is seldom or never used by the customer. Paper prototyping and recording what is actually used, or other usability studies, can suss this out. Since I know you’re in software, maybe a prototype solution is placed in the code and a heat-map and tracker web service ping the dev team each time features are used. The book lean Start-Up proposes placing an icon to fire off the code but having no code behind it, instead displaying a message on click “this feature is coming soon. By clicking here, you’ve just upvoted it on the team’s backlog! Thanks so much!” Ok, some of that is my language, but Lean Start-Up has a similar proposal.
No Comments

Post A Comment