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:
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.
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.
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
In addition to the roles, the so-called artifacts are the three core elements in the Scrum process.
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.”
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.
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:
- Requirements in Story Cards
- Work packages in the product backlog
- Sprint Planning
- Tasks in the sprint backlog
- Meetings in Scrum
- Sprint Review Meeting
- Sprint Retrospective
- Product Backlog Refinement
- 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.
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
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.
Learn more about AvePoint’s Microsoft Teams Management solutions.
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
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
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.
Recently, Microsoft added the functionality to export a plan into the Excel format. Although extra formatting and transformation actions are needed, this new capability enables you to build additional analysis and reporting functions 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!
If I understand you, you create a channel for each user story.
the problem is when we have several user stories, you cannot do any sprint or work package planing, reporting…
Planner boards, charts and schedule are only usable per channel.
I have 2 channels. Each channel has 10 tasks that I spread across 3 sprints.
How can I see a summary of all tasks in sprint 2?
How can you incorporate the Fibonacci Sequence sizing for each task? Right now I have each number written in each Task’s Note section.
This link shows that there’s a way to create a Burndown Chart (about half way down the page) based on the tasks within MS Teams/Planner. Do you know how they created the Burndown Chart?
I’m hoping to integrate everything I do with Scrum into MS Teams, but I don’t know how to create the Burndown Chart and Velocity Chart. I’ve created the Backlog, To Do, Doing, Done as buckets based on your awesome instructions above. And I’ve created tasks for the Sprint during Sprint Planning phase. It’s great that the tasks can be moved by any member on MS Teams from To Do to Doing (across buckets) and we can see it near-realtime (~3 sec delay). But the Burndown Chart and Velocity Chart being incorporated would be great.
The description at that link is not encouraging – note the words “can be manually maintained”
“However, such chart can manually be maintained using the statistics from the Planner itself. Each task can include the estimated/remaining effort info which can assist the Scrum Master in the preparation of the Sprint Burndown Chart.”
Does anyone respond to comments here?
I don’t think so 🙁
How to label EPICS here?