SharePoint Projects Intake Process

Post date: May 02, 2019 5:56:35 PM

One of the major tasks that I had to attend to when I started my new role as SharePoint Architect at my current client is to establish a dev ops for SharePoint OnPrem and SharePoint Online. Started with Azure Dev Ops I quickly recognize that the problem is bigger than that. There is no intake process for new projects either its configuration or actual development or just a client side scripts. It's ad-hoc where the BA's meet with the clients and the analysis is done quickly and dive into solution-ing without checking into the scope, release planning and actually creating SDLC artifacts that are important to track progress as well as document what we are doing.

So, the scope of devops dramatically changed. At this point, I decided to utilize Microsoft Teams to manage the workload starting from inception of an idea to completion. I engaged with my colleague and created a process which feeds on a dev/config opportunity and guide with step by step configuration of Team site to manage requirements, release planning, sprint progress and devOps for final product.

• 1. Microsoft Teams Configuration

  2. The process below defines all the steps needed to start from requirements registered in a Tracker system which we use to track for all requests. For all practical purposes, this can be an email or a list of project registry.

  3. 1. A work item/request comes in via WIP/Tracker 

  4.  

  5. 2. If a channel is needed in Tier1 one can be created (request/provision) 

  6.  

• • Some WIP/Tracker items belong in the existing Fav channels  

  • (e.g. CU Updates would go in the ‘System Administration’ channel) 

• 1. 3. Non-project related work efforts will be coordinated on in a channel in ‘Tier2 – Solutioning’ 

• • In ‘Tier2 – Solutioning’, a new channel will be provisioned in the relevant ‘SharePoint Project - MSTeam’. Each department will have a dedicated ‘SharePoint Projects - MSTeam’ 

  •  

  • If a project warrants provisioning its own ‘SharePoint Projects - MSTeam’ we can do so ad hoc 

• • All of the ‘SharePoint Projects - MSTeams’ will be linked and presented via the ‘SharePoint Projects’ hub shared navigation 

• • We’ll use one Planner within that channel as the Storyboard to include: 

  •  

• 1. a) ‘Todo’ bucket: 

• • Placeholder for the scheduling of a ‘Solution Review’ meeting (we’ll make it the first task by default) 

  • Requirements (requestor, functionality, etc.) 

  • Use cases 

  • User stories 

  •  

• 1. b) ‘UAT Cases’ bucket: 

• • UAT case definitions 

• 1. 4. Prior to project-kickoff, we will conduct a one-time ‘Solution Review’ with the “Solutioner” prior to the start of the project kickoff (i.e. start of the first sprint). 

  2.  

• • ‘Design Reviews’ consists of: 

• 1. a) Solution designs  

  2. b) Work estimates 

  3. c) Defined sprints (in a Planner) and sprint durations 

  4.  

• • The end deliverable of the Solution Review is a defined ‘Release Plan’ (i.e. a Planner) 

  •  

  • After the Release Plan has been defined, we will go back to the business and review for affirmation 

  •  

  • AzureDevOps requirements will be identified within the ‘Release Plan’ and tracked across all the sprints 

  •    Note… we’ll use a separate and reusable ‘Planner’ for the sprints 

• • A wiki will be used for documenting the project 

  •    Note… store files in the files tab and link to them in the wiki 

• • Before adding any back logged items to the Release Plan we will consult with the business (e.g. during the next sprint retrospective/planning) to determine disruption and how to accommodate without unending “sprint creep” 

• 1. 5. Escalation into ‘Tier3 – AzureDevOps’ can occur at any point in the project lifecycle and overlap with sprint(s) defined in the Release Plan 

  2.    Note... At the highest level AzureDevOps is organized by department and then sub-categorized by project. 

• 1. a) An AzureDevOps project is created 

  2. b) Devs will be added as participating members on the AzureDevOps project 

  3. c) A separate AzureDevOps specific Release Plan will be worked on in AzureDevOps 

Snapshot of Team configuration:

Release Plan:

Sprints:

This is a running activity until the deadline of the project is met. This is the view where you copy tasks from the sprint you plan to start in the release plan, in To Do bucket so you can start working on them by creating tasks and moving the stories along as they progress until they are done.

This view is always current to show the current sprint. If there are any items left to finish from last sprint, they will show up here in either In Progress or in QA buckets.