REGISTER TODAY  to learn how to increase organization-wide engagement with our webinar, 5 Ways to Skyrocket Your Organizational Engagement with Yammer!


The Conference Modern Workplace Pros Don’t Want To Miss

Speakers From Microsoft, Forrester, Mastercard, IAPP, CMS and more!

In our first post on project management, we looked at why this management form is successful and how planners and teams can take advantage of the Kanban model. This time, we’re going to take a look at the Scrum method.

Scrum: An Agile Project Management Method

Scrum is not an abbreviation for a term, but simply a concept for agile project management techniques. It was first mentioned in 1986 in the article “The New New Product Development Game” and describes how a team can more quickly implement complex development processes when the team consists of small and self-organizing units. That’s exactly what we need in today’s fast-paced world.

Some agile methods can be relatively unstructured. Kanban, for example, allows users to independently assign tasks to colleagues from a “task basket.” By contrast, the Scrum approach is more process-oriented. To be successful, it needs to be monitored and controlled on a daily basis and under a rigorous performance metric. To achieve this, clear framework conditions must be created.

Scrum Roles and Tasks:

Product Owner

The Product Owner acts in the interests of the users of the product or the stakeholders of a project. Consequently, he is responsible for the success of the project and must prioritize the technical requirements of the project over the entire project period, adding new ones and discarding obsolete ones as necessary.

Scrum Master

This person is responsible for ensuring that all processes are followed correctly. As a kind of moderator, he ensures that the team can communicate successfully, shields them from external disruptions, and helps with methodological issues. In short, his job is to eliminate obstacles preventing effective teamwork.

Scrum Team

Each Scrum team working on a product should be no larger than five to ten people. Each team member should be goal-oriented and be able to work independently on their own tasks.

Last, but certainly not least, are stakeholders. Although they don’t have a central role within the Scrum process, considering their wishes and feedback is key for the project success. Stakeholders can be either a) the clients, b) the eventual end users, or c) the management of the corresponding project.

Interested in learning more about the unique Scrum project management method? Check out this informative post: Click To Tweet

Scrum artifacts:

In addition to the roles, the so-called artifacts are the three core elements in the Scrum process.

Requirements

The goals of the clients (stakeholders) are recorded as requirements and should be described as “User Stories.” These should not be written in a technical form so the real customer use case remains in focus. These requirements are to be implemented into the technical work packages in the “Product Backlog.”

Sprint Backlog

Work packages that describe the features and functions of each product/project and are defined as concrete tasks (sometimes with subtasks) are collected in the Sprint Backlog. A “sprint” is a one month or less-long period of time when small product increments are created.

Product Increment

A product increment is the sum of all items completed during a sprint. They must either be semi-functional versions after different sprints or the finished product at the end of the project.

Roles and artifacts are elements of the overarching Scrum process, which is comprised of:

  1. Requirements in Story Cards
  2. Work packages in the product backlog
  3. Priorities
  4. Sprint Planning
  5. Tasks in the sprint backlog
  6. Meetings in Scrum
  7. Sprint Review Meeting
  8. Sprint Retrospective
  9. Product Backlog Refinement
  10. Project completion

Microsoft Teams and Planner are both incredibly helpful in providing Scrum masters and their teams the ability to work together as effectively as possible. I recommend using them as such:

Scrum Process Activities with Microsoft Teams and Planner

1. Requirements in Story Cards

Roles: Owner, Stakeholder

Application: Teams Channels, Notebook

As described under the “Scrum artifacts” section, client requirements should be focused on features and functions. It is also helpful to use the description as a use case in order to keep the goal of the project front and center in mind. This is key in reducing the risk of misplanning.

Source

For the first step of the Scrum process, I recommend Microsoft Teams. The story cards (i.e. individual features and functions) can be described per channel (1). This also allows more detailed arrangements, files and other specific requirements (2) to be separated.

Alternatively, the OneNote app can also be very well integrated into the team. This tool similarly allows (a) the individual features and (b) use cases to be described. Personally, I prefer the aforementioned version with Teams Channels because it offers more options (chats, likes, @ mentions, connectors, etc.) and flexibility.

2. Work Packages in the Product Backlog

Roles: Owner

Application: Planner cards

In step two, the requirements now have to be translated into professional work packages. Planner task cards are the perfect solution. All necessary information can be recorded in them as previously described here.

3. Priorities

Roles: Owner

Application: Planner Labels

As preparation for step four, the task packages must first be prioritized according to importance or dependency. The labels on the cards are precisely for this purpose.

4. Sprint Planning

Roles: Owner, Team, (Master)

Application: Teams Meeting, Planner Buckets

This step is not just about estimating the individual efforts of the work packages and assigning tasks to a sprint section. Especially at the beginning, it also has to be clear when and where all project members can meet on a daily basis, what the general project build-up should look like, what the project milestones are and which details need to be considered. This is essentially all about coordination between the product owner and the team. I also recommend the inclusion of the Scrum masters to handle the more methodological aspects of the project.

At the end of each sprint planning session the individual work packages from the Product Backlog (1) should be assigned to the respective sprint (2). Planner is the ideal platform for this due to its project bucket functionality. If you can’t meet in person to plan, I highly recommend using the meeting function (including video!) in Microsoft Teams. With it, everyone will be able to either have the task cards in front of them or shared via on the screen.

5. Tasks in the sprint backlog

Roles: Team

Application: Tasks in Planner cards

The work on the task packages, in a sprint, now begins at step five. This should usually take a maximum of one to four weeks and be monitored through daily Daily Scrum Meetings (see step six – Scrum Meetings). For detailed progress planning, I recommend splitting work packages into individual (sub) tasks. These can be defined within each Planner task card.

6. Meetings in Scrum

Roles: Master, Owner, Team

Application: Teams Meeting (Planner Maps Overview)

A central part of the Scrum approach is meeting daily for a maximum of 15 minutes. During this meeting, each member of the team reports on what have been doing since the last Scrum, what they will do until the next Scrum, and what hampers their work. The master can deduce necessary steps to clear these obstacles.

Microsoft Teams provides the perfect foundation for such meetings, especially with distributed teams. As in step four (“Sprint Planning”), each participant can follow the tasks on the Planner map view during the meeting or via screen sharing. Due to the very compact scheduling of daily Scrums, however, one should consider whether this is necessary or if the audio and video broadcast is sufficient.

Sprint Review Meeting

Roles: Master, Owner, Team, Stakeholder

Application: Teams Meeting (Planner Maps Overview)

At the end of each sprint there should be a progress check. Depending on the project and product, a (partial) result release can be completed and presented to the client. He can then accept the result, reject it, give feedback, or even formulate new requirements. This highlights the benefits of agile project management, where you can continually respond to changing tasks.

Compared to the compact daily Scrums, using the Planner task cards as visual support during the Sprint Review Meetings is highly recommended. Nevertheless, the Sprint Reviews should last a maximum of one hour.

With the hopefully available authorization restrictions per team channel (see Microsoft User Voice), an “external channel” can be created with the client, meetings are held and files can be shared without other internal documents becoming available. Until then, however, the current meeting function including telephone dial-up—is an optimal way to hold the sprint reviews with (external) clients.


Which Tool When: #MicrosoftProject or #MicrosoftPlanner?


8. Sprint Retrospective

Roles: Master, Team, (Owner)

Application: Teams Meeting (Teams Channels)

In addition to focusing on the project/product in the Sprint Review, the team should meet separately and discuss the work process. This should be continuously checked and improved.

As an alternative to a meeting, feedback can also be made directly in the team channels.

9. Product Backlog Refinement

Roles: Owner

Application: Planner Buckets

From the results of step seven (“Sprint Review Meeting”), the product owner must organize and update the product backlog. Completed work packages should be marked as completed in Planner and moved to the product log. New or updated tasks can be resumed in the Product Backlog or scheduled directly for the next sprint.

10. Project Completion

Roles: Owner, Stakeholder

Application: Planner Buckets, Teams Meeting

Once all sprints have been completed, the end product can be delivered to the customer. Planner should then mark all task cards in the product log as complete.

Furthermore, thanks to this simple diagram, a product owner always has an overview of his Scrum projects and the status of the tasks they contain.

Unfortunately, Planner currently lacks an export function to transform the information into other formats or to use additional analysis options, such as a burn-down chart (commonly used for Scrum).

Microsoft works tirelessly to implement new features in Office 365 and Planner. As such, the linking of Microsoft Outlook appointments with Planner tasks was recently rolled out. The connection to other Office 365 workstreams is also currently under development, as can be read on the Office 365 Roadmap page.

Regardless of future developments, Planner is already an ideal tool for agile project management and the Scrum approach, especially with its easy integration into Microsoft Teams. I therefore recommend that companies that want to establish agile work structures should try Planner in combination with Microsoft Teams, especially when it comes to small to medium-sized projects.


Want more on project management methods? Subscribe to our blog!