Devops Office 365 Project Management

Managing Projects in a Modern World (Part 2)

In my previous post (Managing Projects in a Modern World (Part 1))I showed an example of an integrated Microsoft Teams, Azure DevOps and Project Roadmap environment. This post is all about setting up Azure DevOps to work with Teams and Roadmap

At a high-level we need to:

  1. Create a project
  2. Setup your teams
  3. Configure your work items

1. Create a Project

Navigate to and sign in with your Microsoft account.

If your organization has never used Azure DevOps. That is OK. You get five free licenses. Once your team gets larger or you choose to use more advanced features then there will be a cost associated.

At the top right of the page you will see a button “Create Project”. Click on the “Create Project” button will open a side bar.

  1. Project Name: The project name should reflect the project you are working on and if possible map it to the name of the Microsoft Team you will be creating.
  2. Description: This allows for you to describe what this project is about so anyone looking through the project list in Azure DevOps knows what it is about.
  3. Visibility: Public / Private. Public is used for open source projects. Private will usually be the correct choice
  4. Version Control: You have the choice between Git and Team Foundation Version Control. Git seems to be the most popular choice these days and most modern web developers will be capable of using it.
  5. Work Item Process: This is the most important choice you will make when creating a project. While you can customize the process you choose you cannot switch between processes. So if you choose CMMI but then wanted to move to a scrum process you would not be able too.

Work Item Process is your most important decision. Make sure you understand your options. Click Here to see the Work Item Process Options.

Once you have filled out the form click on “Create”.

It will take about a minute for your new project to get created.

Once the Project has been created, we can configure it to work for us. We don’t need to use Repos, Pipelines, Test Plans or Artifacts.

  1. Click on Project Settings.
  2. Scroll Down.
  3. Turn off Repos.
  4. Turn off Pipelines.
  5. Turn off Artifacts.
  6. Turn of Test Plans.

This does not remove your ability to use any of the tools. It just hides them until you are ready. Simplifying the user experience. When you are ready turn them on.

2. Create your Teams

While still within the project settings form. Select “Teams” under the general drop down.

Click on New Team and add all of your required teams. In this scenario the teams are broken down by role. This could very well be by features or functions.

When creating new teams you have the option to create a new Area path. This is helpful when you want to separate your backlog of tasks to each team. You will also be able to have separate sprint lengths.

The area path is what allows us to have channel specific Kanban boards.

3. Update your work items

For Azure Devops to work with Project Roadmap we need to have a Start Date and a Finish Date on a work item. Depending on the work item process you chose you may or may not have a start and finish dates on your work items.

In the case of this example I chose the “Basic” template which gives us “Epics”, “Issues” and “Tasks”. By default the epic does not have a Start Date or Targeted Date.

I would like to use epics on my project roadmap so to do so we can add the start and finish date.

The easiest way to do this is when creating a new Epic on your back log:

Once you are in the “New Epic” screen, click on the actions button on the far right.

Then click on “Customize”.

This will take you to the organization settings process page.

Click on “New Field”, then use an existing field.

Add the Start Date and Target Date. Your Epic layout should now look like below:

Now, when we create a new Epic, we can add a timeline to it:

Our Azure DevOps environment is now set up and ready for use. The backlogs can start to be populated and added to teams and project roadmaps.

Devops SharePoint

Mike’s 2019 Predictions

With 2018 over and 2019 just beginning I thought it would be fun to make a few guesses as to what I think will happen around the technologies that I work with on a daily basis.


  • SharePoint Online Intranet projects move from boxed solutions back to OOTB then back to boxed
  • SPFX will play a larger role in a SharePoint Developers toolbox.
  • Serverless architectures will move from trial, curiosity and POCs to mainstream first class architectures

Intranet Projects

Currently there are a variety of different boxed solutions for corporate intranets. Examples would be GO, Bonzai, and Sparrow. These are all great solutions to get your intranet done quicker and lower the development time to create an engaging intranet.

The downside is that you are tied to a specific vendor. Locked in for a support contract with no real options to move if you are unhappy with them for what ever reason. These intranets are based off of classic publishing sites templates. While not necessarily bad, Microsoft is just not investing in this space anymore.

Microsoft has rearchitected the way SharePoint sites work. With the release of Hub, Modern Team and Communication sites and with the most recent updates to these site templates. I feel most organizations can finally start to build OOTB Intranets that look custom, look on brand, and are relevant to the users consuming the content.

While the makers of Go, Bonzai, Sparrow and others figure out their best path forward on how to create useful products in this new world. Organizations will start to leverage these new updates in their intranets as first step instead of as an addon.

SPFX — SharePoint Framework

The SharePoint Framework is a client-side development toolkit that allows you to build Webparts and extenstions for SharePoint Online, SharePoint 2016 with FP2 and SharePoint 2019 and most recently Teams.

The ability to write a solution once and have it work in any modern SharePoint environment and Teams is huge win for developers and the money counters. SPFX being entirely TS or JS based fits quite nicely into organizations DevOps strategies.

SPFX is the best way to write web parts for modern SharePoint sites.

Serverless Architectures

As SharePoint developers adopt SPFX as their main way to create web parts for SharePoint and teams. Some functionality will be lost. The ability to run server side code. This is where I think serverless architectures will start to take off more.

Since SPFX is entirely client side facing developers will need a solution to deploy and client side code that they may need. The answer for this in the Azure world will be Functions and Logic Apps. In the amazon world it will be Lambda.

The idea being that instead of creating an entire infrastructure to host what is most likely a small piece of logic. We have these serverless architectures where our logic is hosted and called only when it is needed. Saves a lot of time and money.