You’ve been redirected to SolutionsIQ.com. BigVisible and SolutionsIQ have joined forces, and–lucky you!–you still have access to all of that awesome content. Dig in.
A couple of weeks ago I was leading a story mapping workshop. As I was explaining the process several questions came up around knowing when things would get done. Since we were just getting started, that moment was not the time for a answering questions of when.
When to Answer When
The work of turning ideas into product features involves many questions, only one of which is when. The trick is when will a feature or set of features be complete is not directly answerable. All the other questions and their answers feed the schedule answer and cannot be ignored. We can answer when only as we answer the other needful questions.
The obvious answer is that you want to get paid, to make a profit. It is possible that the motivations to do the work are more and different than profit. Motivations have bearing on schedule.
Who your users are and the market you are targeting certainly effects when the work needs to be done. Different markets and different users have their own needs for timing and expectations.
What the product does and what value it brings to your customers are among the more important points to understand well.
The development teams answer this question by understanding technology, tools and experience. Estimations are part of the how answer because size of effort is directly tied to the people doing the work.
We can only answer when, when [grin] we have answers from the questions above. When sits in the middle of all the other questions and is directly affected by choices we make in their realms.
See how it is hard to say when?
Agile Planning and When
Part of the power in Agile frameworks is the separation of product questions so that they each get the attention needed. Agile frameworks only work well when feedback from all the other questions helps determine when. Agile frameworks give us two ways of answering when and only one direct manipulator of when.
The first way is fixed date, variable scope: When the date is fixed, it’s still just a day on the calendar. In this case the number of features that will be completed by that date, the scope, is necessarily variable. (Even if we don’t want it to be.) We ship everything that is complete on that date. Since Agile frameworks require that the product be maintained in a shippable state, picking a ship date is not hard.
The second way is variable date, fixed scope: If the minimum marketable feature set is large, meaning we have defined a fixed scope of features, the ship date is variable. When to ship is answered given by the date all of the minimum features are complete.
(It is important to note that Agile frameworks do not provide for a way to have both fixed schedule and fixed scope. Neither does any other way of working. It is just that we pretend that we can fix scope and schedule. We in the software industry have been largely failing to do fixed schedule and fixed scope software development for decades. Agile frameworks are empirical processes, where we adjust our work based on the information we gather while doing the work. Fixed answers to when and what are not supported in empirical work. But this is a larger and different discussion.)
The one direct manipulator for answering the question of when is priority. In other words, we can ensure a feature is done before a given date by deciding to work on that feature first. This is why it is so important to take the time to order your backlog with the most important, valuable, risky, etc. features at the top, to be worked on and completed soonest.
Division of Answers
Agile frameworks provide for a division of responsibility in part so that we can get answers to these questions. This way each question is supposed to get deserved focus. For example, in Scrum the Product Owner is the role that focuses most on the question of what should be created. The development team owns the question how. The teams help stakeholders and others answer who and why. These divisions are not walls but areas of focus, as every role informs the other roles and questions. And every question feeds to answer when.