Enterprise Planning

I have lots of questions but I'm going to try to stick to just a couple... 

• Are the team's highly specialized? What is requiring them to have 8 long weeks of planning with each other? 
• Has the enterprise identified what their products are? It sounds like they're looking to just come up with projects that they can then push to teams to work on during this 8 week period. 

I'm trying to understand the need for an enterprise wide planning and backlog. 

@Tony Divel Same sentiments here. I would love some clarity on the following:

• What is the goal of this exercise? Is the adoption of SCRUM itself is the goal (or treated as a product)? 
• What is the basis of formation of cross-functional teams? for e.g. authority, seniority, skill set? 
• Has the enterprise understood Scrum Values? 

From the given information, it seems like the cross-functional team is told to use waterfall to implement the Scrum. 

Daniel, one question that stands out to me is - "What is the product?"

If your organization is about to embark on Scrum, do they intend to honor each of the Scrum Roles?   If so, how does the Product Owner(s) fit into your above 8-week planning session?

Scrum isn't about identifying a fixed scope of work (projects), and then chunking it up in 2 to 4-week iterations.   That is just laying mini-phases on top of a waterfall plan.

I guess another question that stands out is - "Where is the empiricism?"   Without empiricism, and the ability to process feedback to change/pivot your direction, you simply are not doing Scrum.

Add me to the list of "I'm not sure I understand what you are doing".  A few more clarifying questions.

...they will have a set of stories, (or features is what they call them) identified that are achievable to be worked on over an 8 week period (4 2-week sprints)....

Where did these "features" come from? And how it is known that they are achievable in 8 weeks? And if it is already know that it will take 8 weeks, why do you need 8 weeks to discuss them and come up with a plan?

Is the "enterprise backlog" for a single product?

What does the Scrum Guide say about the types of backlogs and what is contained within them?

And I really do not mean any offense by these next statements.  Has anyone at your company actually read the Scrum Guide? Is anyone there knowledgeable of Scrum? Because as the Scrum Guide states:

Scrum is free and offered in this Guide. Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.

Nothing you have talked about is in the Scrum Guide so I question if you are trying to use Scrum.Your statement of "about to embark on SCRUM" makes me ask what is this SCRUM of which you speak?

If you can clarify some of the points we have raised, we may be able to provide you some better answers.

where they will have a set of stories, (or features is what they call them) identified that are achievable to be worked on over an 8 week period (4 2-week sprints).

@Daniel Max, The 4 x 2 week Sprints you are referring to, makes me wonder if you are talking about a Program Increment, i.e. SAFe.

So, it will be 8 weeks of planning (grooming) and 8 weeks of execution.

Even then, planning will happen only 4 times, i.e. once every 2 week Sprint (assuming the base framework is Scrum). FYI, "Grooming" is not the same as Planning and "Grooming" has been replaced with "Refinement" even in SAFe (atleast as per my understanding).

• As the enterprise backlog (EA) is filled and groomed, is it recommended that each cross-functional team have their own backlog and sprint backlog?  EA backlog --> team backlog --> team sprint backlog

Per SAFe, the short answer is yes, because each team has a team backlog.

• Is there a recommendation on how the overall cross-functional planning should occur such that the execution teams can achieve success? 

From an agnostic standpoint, when scaling, the best way to plan, is all teams together, and to reduce/minimize any dependencies.

I appreciate everyone's comments.

So features is the term that's used here but essentially they are business requirements or user stories.  For example, a feature might read "Enable the customer to execute a bank verification check on the applicant".  Not your classic user story but the intent is there.

So, the team is not specialized and many have not been exposed to AGILE/SCRUM.  Also, it is not limited to one product but many.  Essentially, the goal is to look at our application intake for all current systems in production and develop a backlog of enhancements.  

I envisioned that the after going through and identifying which enhancements are identified, sized (hrs - effort) and prioritized in the enterprise backlog, the work would then move the execution phase.   My initial thought is that each team (e.g. product team) would then have their own backlog and sprint backlog.

Keep in mind, in some instances the work that’s identified during the planning/sizing phase may not be cross-functional and be limited to that specific product.  I would say that this occurrence will likely be 50/50. 

I understand that our team is approaching SCRUM in a not so orthodox way – meaning they are taking enhancements from our intake system, time-boxing which items need to be worked on and then moving them to an execution phase where this activity is more in-line with SCRUM.  

Thoughts?

Why do you think an “execution phase” would be more in-line with Scrum?

The execution phase will run like the typical Scrum process - planning, grooming, sprints, stand ups, etc.  My line of questioning revolves around the intake process and the proposed approach of the 8 weeks of estimating and prioritizing the work.

I understand that our team is approaching SCRUM in a not so orthodox way

I known this is not what you want to hear Daniel, but it isn't that you are trying to practice Scrum in an unorthodox way, it is that you are simply not doing Scrum.   Not sure what we can help with here.   

Please consider all of the comments made in this thread - a lot of good advice and questions.

Reconsider, for example, that an "execution phase" is typical of Scrum, and that estimation and prioritization are somehow taken care of in advance.