Skip to main content

When is a Scrum or SAFe project expected to generate revenue?

Last post 05:49 pm January 3, 2024 by Karl Egan
3 replies
05:44 pm January 2, 2024

Can anyone tell me if it is common practice (or even appropriate) to 'sell' iterative releases within a Scrum/SAFe project delivery?  

My understanding is that the iterative development release approach aids to accelerate the maturation of the final system development & delivery through iterative feedback such that at the end of the project (after 'n' iterations) the customer then pays for the product in which they have been an instrumental collaborator.  

i.e. if a Product Manager wishes to 'sell' 2 releases within a single project, should this in fact be 2 projects & not one with 2 sellable releases?

Any guidance greatly appreciated.


07:38 pm January 2, 2024

Think of it the other way around. The most important project is the Sprint, precisely because at least one Increment of immediately usable quality must be produced no later than the end of it. That's the mindset to adopt, and to encourage in others. It's a matter of innovation. The more Sprints are purchased, the more innovation runway there is for learning to build the right thing at the right time.


08:20 am January 3, 2024

As part of Product Ownership, a Product Manager has multiple choices for "selling" and "releasing". There is no one single "correct" way.
I have worked with different clients in different situations, all using the Scrum framework, that might give some ideas:
A machine constructor used Scrum to reduce technical risks as quickly as possible. The end product could only be provided to users after extensive testing of the full machine. This first sale was only possible about 2,5 years after launching the initiative. Sounds like your case.

In another case, a software platform is provided to customers with a number of features. Customers pay a license fee. Depending the license there are more or less features available. Sprint after Sprint features are improved or added. There is no change to the licensing strategy. It is up to customers to upgrade their license if they want access to additional features. This is a totally different scenario.

Yet another case is a solution builder (both hardware and software), that typically partners with a company to build a solution for their problem. Later on the solution is extended with other features for clients with similar, though or slightly different challenges. In this case (irrespective of intermediate releases), the first client pays for their release(s), while other clients pay for their (later) release(s). Sounds more like your second scenario.

In the end it is really up to the Product Owner (a.k.a. an agile Product Manager) to decide when to release, and to decide how to get revenue; i.e. decide on a release strategy and decide on a pricing strategy.
These are complementary practices to the Scrum framework.
 

Hope this helps.
Feel free to shoot more questions!
 


PS You might be interested in my blog posts about the fundamentals of the Scrum framework. If so, please check out this page: https://boostyourscrum.com/professional-scrum-foundations-series/


11:23 am January 3, 2024

Many thanks. 

So now I am aware that selling incremental releases are not unheard of I now need to establish what product launch/sales attributes should be applied to each sales release compared to the type of product launch that would typically come at the end of the development.  

Many thanks for your clear responses.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.