Idea->Demand->Enhancement->Story. What is the ideal flow? How to prevent duplication?

[jamesmcwhinney]

We are in the process of implementing demand management and I am struggling to understand the correct approach as it pertains to enhancement requests & stories.

Our current process is:

1. Incident logged by end user to request a functionality change.  (Because even if we did allow them to log ENHCs directly, we generally cant expect our users to know the difference between an enhancement request vs an incident).

2. BA or development team member closes out incident and creates a new ENHC record.  User is directed to follow the ENHC going forward.

3. enhancement is reviewed, scoped out, approved, and assigned to a release.

4. The release moves into development.

5. The enhancements in the release are developed and moved forward for testing. (We have not used stories for reasons I will highlight later on).

6. The release is tested

7. A change request is submitted for the release to push to prod.

8. The production release is performed, the change request is closed, which closes out the release, which closes out all ENHCs in the release.

We now want to introduce demand management. I have a few questions:

1. What is the official definition of a demand? What is the definition of an enhancement? How do they differ?

2. Is it safe to say that an enhancement generated from a demand is a fully approved and fully scoped out enhancement?

3. Is it right to link an ENHC directly to a release? or would the ENHC typically be converted into stories, and the stories then attached to a release.  If so? How is the end user expected to keep track of the status and ETA of their request as stories could be tied to multiple releases?  As far as they know, they logged an idea.  Behind the scenes there is a demand, then enhancement, and multiple stories - none of which they can see.

4. If the correct approach is truley idea->demand->enhancement-Story, potentially one to many in some cases, and each record has its own discussion thread, how do we keep everything in sync?  Do we have to recopy the information each time we move from one to the next?  (Note that even if we did all of the discussion thread doesnt transfer accross).  If new information is added by the requester in the initial idea record, how does that translate into updates all the way down the line.

Conclusion:

I am struggling with how idea->demand->enhancement->story doesn't ultimately result in mass confusion and excessive overhead for all involved due to 4+ different records to track the scope and state of an update to a business application.

Hoping someone can set me straight.  Thanks in advance!

[Wesley8]

These are all excellent questions, and I have tried to be concise in my answers.  New York offers significant improvements in the Ideation module, so you will want to review that functionality.  Also, a group of sponsors can enter a demand directly and skip the idea.  That functionality is was in the London release.  SN is very flexible to your workflow.  We have tried to stay OOB on most processes. However, we have added a sponsor field to the ENHC table, as explained below.  We chose to add the sponsor field after input from others on this ITBM forum and working with our PPM vendor Rego.  I would recommend talking to an ITBM service vendor; we used Rego.

1. What is the official definition of a demand? What is the definition of an enhancement? How do they differ?

Demand - Our customer's desire and willingness to pay for and/or use a product or service. Demand management is a strategic request from the business to IT and automates the steps in the investment decision process.

Enhancement - An enhancement is a noteworthy improvement to the product as part of a new version of it. The term is also sometimes used to distinguish an improvement (enhancement) of some existing product capability from a totally new capability.

Differ - A demand is where the noteworthy improvement is prioritized against everything else.  In our world, we have defined an enhancement that is less than 40 hours.  If the demand is more than 40 hours, we handle the request as a project.  I have attached a Visio that was from the SN PPM training and made some changes for our environment.

2. Is it safe to say that an enhancement generated from a demand is a fully approved and fully scoped out enhancement?

Enhancements can, but they don't have to go through our full demand approval process for work over 40 hours. We leave it up to the discretion of the service owner to work with their stakeholders to prioritize enhancements.  As shown in the Visio, Enhancements can come from a number of places: 1. Idea-> Demand-> Enhancement 2. an Incident -> Enhancement 3. directly from service owner 4. previous optimization discussions.

3. Is it right to link an ENHC directly to a release? or would the ENHC typically be converted into stories, and the stories then attached to a release.  If so? How is the end user expected to keep track of the status and ETA of their request as stories could be tied to multiple releases?  As far as they know, they logged an idea.  Behind the scenes there is a demand, then enhancement, and multiple stories - none of which they can see.

For the idea or demand sponsor, SN doesn't have a field for an original sponsor, so we added it to that ENHC table.  The new ENHC sponsor field inherits the Submitted By field from a demand. However, the ENHC sponsor field can be updated if the ENHC comes from another of the workflows.  Now that we can track the original sponsor from our ENHC field.  Also, SN Agile 2.0, wants you to create stories, so we have either a 1 to 1 or 1 to many relationship between enhancements and stories.  We then assign stories to releases.  We also created a separate dashboard report that allows us to see all the enhancements included in a release.  The service owner works with the stakeholders to publish what enhancements will be included in what release.  The SN update to the Idea is shown in the stage field, not what release that idea will be included in.

4. If the correct approach is truley idea->demand->enhancement-Story, potentially one to many in some cases, and each record has its own discussion thread, how do we keep everything in sync?  Do we have to recopy the information each time we move from one to the next?  (Note that even if we did all of the discussion thread doesnt transfer accross).  If new information is added by the requester in the initial idea record, how does that translate into updates all the way down the line?

In sync, that's a great question.  There is some copy/paste during the analysis. However, the in-sync process happens as you move through the process of delivering a solution.  There is a field called Stage on the Idea and Demand field that is updated as the work progresses.  New information is included as you move through the solution delivery process.  SN ideas, demands, enhancements, stories, releases all aid in prioritizing and getting work done. However, there is still a need to keep a service/product road map that is published to stakeholders.  As well, the SN Agile assumes you are following the four values of Agile and new information is baked into Individuals and Interactions Over Processes and Tools, Working Software Over Comprehensive Documentation, Customer Collaboration Over Contract Negotiation, Responding to Change Over Following a Plan

Hope this helps.

[jamesmcwhinney]

Thank you so much for this Wesley! This is immensely helpful.

Most of this makes sense to me, I just struggle with a few key aspects:

1. If the request has already been elaborated on and prioritized via demand, what value is there in creating an ENHC over stories?  what information does it contain that isn't already in demand? why do we not go directly to stories?

2. Could you provide a little more detail around the synchronization aspect?  This is the aspect I struggle with the most.  For the requester who submitted the idea or the collaborators on the demand, do they have any visibility of the ENHC and its underlying stories.  Are you saying the idea module automatically surfaces information from the downstream records? even if they are one to many? Or are you saying they have only very high level visibility, and generally speaking users should refer to product roadmaps to try and decipher the ETA for their requests.

3. As requirements evolve at the story level, is any work done to go back and update the parent ENHC, and the parent Demand, or idea?  If not, are we setting the expectation that those intermediary records have served their purpose and should no longer be referenced as a source of truth?  Otherwise how do we prevent confusion by those who would read those records and expect X while the underlying stories will be delivering Y (due to discussions that took place later on).

Thank you again for sharing your thoughts on this. 

Greatly appreciated!

Cheers,

- James

[Wesley8]

I will say that we are new to PPM and our PMO is maturing.  We are small shop, about 45 folks, so we don't have hundreds of projects with global reach.  We are a mix of waterfall and hybrid work.  We are trying to move in an Agile direction, however at this time we are using some of the Agile tools within SN, but we are not an Agile shop.

We do have Idea / Demand modules in play.  As I indicated we categorize any work of 40 hours a project, the other we consider as an Enhancement or Change.  

As well, take some time and look at the PPM blogs that Kelly Kaufmann and I have written.  Those should help too.

1. If the request has already been elaborated on and prioritized via demand, what value is there in creating an ENHC over stories?  what information does it contain that isn't already in demand? why do we not go directly to stories?

Well, the short answer is that in SN, the only two options are to promote an accepted demand to an Enhancement or Project.  The demand has the completed business case for the work that an organization believes needs to be prioritized, and yes, this demand record should be updated if there is something that is relevant to the work.  We treat the demand as our charter or one-pager.  Sure, if you are fully and Agile shop, the enhancements are about features, epics, and themes.  The ENHC is owned by a service/product owner.  In SN, this is the backlog.  With New York, you can now create Stories from a Demand, however, the Demand record still is either a project or an enhancement.

2. Could you provide a little more detail around the synchronization aspect?  This is the aspect I struggle with the most.  For the requester who submitted the idea or the collaborators on the demand, do they have any visibility of the ENHC and its underlying stories.  Are you saying the idea module automatically surfaces information from the downstream records? even if they are one to many? Or are you saying they have only very high level visibility, and generally speaking users should refer to product roadmaps to try and decipher the ETA for their requests.

In SN OOB, none PPM users can view Demands and Ideas they have created.  A requester doesn't have access to the Enhancement list unless you give them access through the Agile role.  Yes, the Idea and Demand have a Stage field that is updated based on the updates from the project or enhancement.  There isn't a one to many relationship between a demand and an enhancement/project.  This is a one to one relationship.  Yes, there has to be a product roadmap.  One of our teams has 4 published releases that ENHC will be delivered through the year.  The team is working with the stakeholders to prioritize their work based on resource availability.  As well, some ENHC can be released upon completion in a sprint is that is appropriate, but yes a services/product roadmap is required.  I will say SN doesn't have a lot of features for the product/services mgr for roadmaps.  There are some nice graphics in the portfolio and demand workbenches, however, for presentation, these roadmaps are visually displayed outside of SN.  I have seen the product Aha! and it is pretty slick however we don't use it.

3. As requirements evolve at the story level, is any work done to go back and update the parent ENHC, and the parent Demand, or idea?  If not, are we setting the expectation that those intermediary records have served their purpose and should no longer be referenced as a source of truth?  Otherwise, how do we prevent confusion by those who would read those records and expect X while the underlying stories will be delivering Y (due to discussions that took place later on).

For us, no we are not going back and updating, however, the demand manager could.  Think about a project charter and how you currently handled an updated charter.  We simply document updates in our project or portfolio progress reporting.  We also try to do an after-action review so any updates on the scope are captured there.  We are also moving in an Agile direction and i have shared those values in my last reply