related set of features, which will guide us in deciding how much to invest.
With defined expected outcomes and investment, a team can come up with the suitable set of software features and enhancements to support the investment and achieve the goal, or decide that such a delivery is unrealistic early on.
Instead of estimating how long a set of features will take to develop, we can invest in building features up to a certain level of quality. This is where User Stories fit in perfectly and where a clear definition of quality ensures a shared understanding. By delivering the features–fourth and fifth level deliverables–we should get parts of the expected results for parts of the investment. We can then measure the outcomes of increments and validate our business assumptions early.
For example, in order to increase the number of users ("why"), a company might want to stimulate existing customers (“who”) to invite their Facebook friends to sign up for a product ("how"). The business can decide to invest 100.000 GBP and one month of development time in improving the way fans can invite their friends to sign up for a product through Facebook, expecting that this will give them 50.000 new users over 6 months. The team can then suggest ways for the software to support such an investment, for example offering some kind of personalisation ("what"), which can lead to 5-6 suggestions of user stories that improve the software in that area. Each user story should ideally deliver a slice of the value, so it should create a visible effect on the number of new users. Although the expected total improvement is specified on the level of six months, the sponsors and the delivery team can come up with a scaled down short term indicator of what they expected from a particular story.
After the first few stories go live, the sponsors can check their assumptions about the value of Facebook invitations against those indicators much before the entire investment is spent. This can either validate the assumptions and confirm that further investment in invitations or personalisation is justified, or lead to a reprioritisation from a business level because the indicators are not there. In addition, if the expected outcome is achieved sooner, for example if the few early stories already deliver much more than the expected indicators, the business might decide to stop investing in invitations and shift the focus somewhere else.
Effect Mapping, as a process, helps to drive the project implementation scope towards delivering the right business effects. The resulting mind maps provide a good visualisation of software project scope for the sponsors to effectively track progress, plan and prioritise without micro-managing and getting involved in minute delivery tasks. Effect Maps facilitate the implementation of User Stories for short term planning, measurable well defined outcomes for business prioritisation, focusing on minimum marketable features for highest return on investment. They help teams to implement other good iterative product management practices. In addition, my assumption (which I plan to verify the first time I get the chance) is that it will help to switch the mentality from cost to investment for IT projects, and facilitate the business delivery for the return on that investment.
- [Balic07] Mijo Balic, Ingrid Ottersten, Effect Managing IT, 2007, Copenhagen Business School, 978-8763001762
- [Cohn04] Mike Cohn, User Stories Applied for Agile Software Development, 2004, Addison-Wesley Professional, ISBN 978-0321205681
- [Weinberg91] Gerald Weinberg, Quality Software Management, 1991, Dorset House Publishing, ISBN 978-0932633224
- [Adzic11] Gojko Adzic, Specification by Example 2011, Manning, ISBN 9781617290084
- [Berkun05] Scott Berkun, Art of Project Management, 2005, O'Reilly, ISBN 978-0596007867