Question (how to measure product success/values )?

Given that in Scrum a product is delivered iteratively and incrementally, is it really appropriate to talk about a successful "product" at all?

Wouldn't it be better to think in terms of each increment and/or release, and how successful a Sprint has been in meeting its goals?

@Lan: Thanks.

yes you are right. I repeat my question in following example.
let's assume a company is planning to create a new app for smart phones which support the tourists with current Informations about Paris. The current release plan shows 6 monthly sprints is needed to finish it and the PO plans for two releases. first after sprint 3 with limited feature and second after the sprint 6 (full version). If the app has success they plan to extend it to other attractive touristic cities : barceloln ,.... in rel. 3,...
The app in rel. 1 is free and update into Rel.2 (full version ) will cost some money.

Now what are the relevant factors (metrics) to measure if an increment / release was successful.
How does a PO measure/ define/ evaluate the value of a piece of software?
lets say higher management (CXO) needs this evaluation (Quality Gate) before give green light for rel.2

I think even classical product managers should have such tools/methods for evaluation. Could you suggest any link or book which covers such topics?

Mehdi

> How does a PO measure/ define/ evaluate the value of a piece of software?
> lets say higher management (CXO) needs this evaluation (Quality Gate) before
> give green light for rel.2

Higher management is not responsible for product value in Scrum...the Product Owner is. It is perfectly reasonable for management to hold the PO accountable for the return on investment, but it isn't up to them to "give the green light" for release. That's all part and parcel of what the PO is supposed to do.

The PO should make this evaluation each and every sprint. There are no "quality gates" in Scrum within which increments are allowed to batch before release. Each increment must in itself be of sufficient quality to be potentially releasable. That's what the Definition of Done is for.

The situation you describe is a common one, and it is representative of the class of problem that SAFe appeals to, but it isn't a Scrum way of working.

> I think even classical product managers should have such tools/methods for evaluation.

Yes they would. That's because they do long-term release planning with batch sizes greater than a sprint allows. They plan the anticipated benefits of the product accordingly.

Release planning is no longer part of the Scrum Framework. Instead, each increment must be potentially releasable, and the decision to release can be made on an ad-hoc basis by the Product Owner. The result is that batch sizes are constrained to the work of one sprint, and agility is therefore optimized.

> Could you suggest any link or book which covers such topics?

Scrum doesn't prescribe *how* a PO evaluates an increment in terms of its quality. That's a huge topic and it's very difficult to give good general advice.

I suggest you might want to look at "The Lean Startup" by Eric Ries. This describes product evaluation in terms of validated learning, and of having an MVP that allows market hypotheses to be tested as efficiently as possible.

@Ian: Thanks. your description was , as usual very helpful.
I have ordered the book and I will read it soon.
You do not like the Scaled Agile Framework™ (SAFe) method, do you?
May I ask what is your preference scaling model in enterpreis level? scrum of scrum?

Mehdi

> You do not like the Scaled Agile Framework™ (SAFe) method, do you?

I've used it before on a project, and am slightly on the negative side of ambivalent. I don't like how SAFe is advocated as being an "agile" framework even though it patently isn't one. That does the industry no favors, since it confuses people's expectations and the terms of reference they rely upon. I do like the fact that SAFe leaves many organizations better off than they were beforehand, even if they don't achieve genuine agile practice. I admire the value it places upon clear executive sponsorship.

> May I ask what is your preference scaling model in enterpreis level? scrum of scrum?

I see Lean Startup as a valid scaling model in its own right. A few months ago I asked Eric Ries if he concurred with this view of its usage. He broadly concurred, although he prefers to avoid such explicit positioning as it might increase resistance to the adoption of its practices.

Scrum.org's Agility Path seems like it might be a viable mechanism for scaling, though I have no experience of using it.

In common with others on this forum I also value the work of Larman and Vodde.

Hi Ian, I like you analysis of measuring product success/values. I will just add that it "should'nt" be difficult for the PO explaning to stakeholders that success/failure cannot be defined upfront especially when the increment has not been reviewed, but usually this is not the case. Stakeholders are always wanting undefined needs...

May I ask a question? 

How do I define success factor(s) for a scrum implementation process that is yet to kick-off? My domain lead want me to come up with list of success factors, I can easily come up with things like: reduced risk, increased product quality, quick feedback loop, business involvement etc. But I'm not a salesman and I don't want to come up wish lists which will be difficult to meet within few weeks. How can this be managed?

In Scrum, the leap-of-faith stakeholders are expected to make before seeing results should never exceed 1 month. That's the critical success factor. There must be empirical evidence of successful delivery each and every Sprint.