How to compute
Hi,
First of all I want to I apologize if this topic appears to be off-topic.
I'm new here and I was initially searching for a more general forum about project management to ask my question. However, strangely, I haven't been able to find one that looks up my alley.
Thereby, as a SCRUM believer-and-activist, I refined my research and ended on your forum that I hope will be helpful to me when it comes to talking about scrum or about anything else related to software project management overall.
If it doesn't then feel free to lock the topic and any good address for a better forum will be appreciated.
My team and I are on the verge of kicking-off a new product and we've reached the point where we're facing six different alternative products. Every product has been estimated in terms of time and risks.
Our management and we are trying to figure out what'd be the fittest one for everyone, that is:
- The team (technologically and enthusiastically talking)
- The steering board (financial-wise)
- The market obviously (sales-wise)
Therefore we were asked to deliver a small feedback about our personal thoughts about it.
In order to help us, I'm trying to come up with a "scale" that would summarise in one number -and one number only- the between:
- The eagerness of the team towards a product (on a scale from 0 to 5)
- The risk of the project (on a scale from 0 to 5)
- The length of the project (in months)
I've already found some risk and risk-averse stuff that are used in Economics but, although I'm actually quite keen on Economics (!), this isn't quite suitable to my situation.
Therefore I was wondering whether somebody would know an easy formula to compute this by any chance? It's kind of a opportunity-challenge ratio (seeing the enthusiasm of the team as an important opportunity).
Thank you very much
Ah damn, I've slipped on the tab button while writing the subject of this topic and it seems that I cannot edit it anymore unfortunately. Could a moderator perhaps complete it manually with "How to compute a opportunity-challenge ratio for a project?". Sorry about that.
> My team and I are on the verge of kicking-off a new product and
> we've reached the point where we're facing six different alternative
> products. Every product has been estimated in terms of time and risks.
Don't try and predict this. Instead, you should create a very small MVP to test the most credible market hypothesis. The process should be one of validated learning and innovation accountancy, not prediction, and you should take a serious look at the options for incremental funding.
I suggest you have a look at "The Lean Startup" by Eric Ries for more guidance on how to do this. Eric originally framed this using an Extreme Programming approach, but as long as the Product Owner maintains an entrepreneurial view Scrum can also be used.
Hi Ian,
What do you mean exactly by creating a small MVP to test the most credible market?
If I understand you well you mean developing a small app and launching it to get a first feedback? That's not really our company's strategy for this ongoing new project and discussing this isn't really the topic right now. Nor the topic of my initial question. They've already made their own forecasts of the potential sales for each of the products we've got in mind. Nevertheless we're the team and as a matter of fact we're only here to say how much it'd cost, not how much it'd yield to the company.
Btw! I've never heard about "The Lean Startup" though and albeit it seems to be more aimed at startups I might have a look at it indeed. Thanks for the reference! :)
My idea would be so far to do for each project the following: estimate the eagerness of the team and the easiness of the project on a scale to 0 to 5 (because they are 6 products), sum these two figures and divide them by the number of months and then multiply this by the forecast. It could a good overview between the different parameters involved I think.
> What do you mean exactly by creating a small MVP to test the most credible market?
...
> Btw! I've never heard about "The Lean Startup" though...
Check the bottom of page 2 in the PDF you recently posted a link to...the one on agile scaling at Spotify. It says:
"Squads are encouraged to apply Lean Startup principles such as MVP (minimum viable product) and Validated Learning. MVP means releasing early and often, and validated learning means using metrics and A/B testing to find out what really works and what doesn't".
That's what I'm talking about, though I am thinking in terms of traditional Scrum Teams rather than squads (which the article holds to be similar). Either can be designed to feel like a mini-startup, assuming they have Product Owners with an entrepreneurial vision.
If you'd rather take a predictive approach you should be aware that there are real dangers in this, as you can end up chasing a dud and end up "achieving failure". In an agile way of working, teams do not leave it to management to take such risks. Instead, they'll release early and often by applying the kind of principles which the Spotify article describes:
https://dl.dropboxusercontent.com/u/1018963/Articles/SpotifyScaling.pdf
Interesting that I've always overlooked at the reference to the Lean Startup principles in this very same article that I've posted... funny it's related to this topic as well, it seems that sometimes things are meant to be like they say.
You're preaching the choir for the rest. The problem is that so far it's really difficult to have this bottom-up approach in our company I'm afraid. So again, I understand I can't have another kind of answer from a scrum crowd but, although it sadly makes me realize once more that there're many things wrong in the way we approach agile, this isn't really the answer I'm aiming for right now.
I'm going to trigger a few things internally here about this Lean Startup thingy though so be sure your answer was by far not useless to us. :)
> The problem is that so far it's really difficult to have this bottom-up approach
> in our company I'm afraid. So again, I understand I can't have another kind of
> answer from a scrum crowd
In the mean time check out "Using Economics to Prioritize your Backlog":
http://www.rallydev.com/community/agile/using-economics-prioritize-your…
don't forget the link to Johanna Rothman's article on Point Play:
http://www.jrothman.com/2009/06/point-play/
These aren't exactly what you are looking for but you could mine them for ideas.