the POWER BRICK for
Building your own Sprint Planner with Microsoft Teams - Tasks & Lists
You love the idea of using Microsoft Tasks for your planning. It comes with no additional costs, and have great integrations. But you will find your self lacking fundamental capabilities like supporting the estimation process with Planning Poker and the progress tracking and team motivation with Burndown chats. Jumpto365 has the PowerApps & List based DIY kit to fill that gap.
You get 3 PowerApps included
And features like
Planning Poker is an agile estimating and planning technique that is consensus based. To start a poker planning session, the product owner or customer reads an agile user story or describes a feature to the estimators.
Each estimator is holding a deck of Planning Poker cards with values like 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100, which is the sequence we recommend. The values represent the number of story points, ideal days, or other units in which the team estimates.
The estimators discuss the feature, asking questions of the product owner as needed. When the feature has been fully discussed, each estimator privately selects one card to represent his or her estimate. All cards are then revealed at the same time.
If all estimators selected the same value, that becomes the estimate. If not, the estimators discuss their estimates. The high and low estimators should especially share their reasons. After further discussion, each estimator reselects an estimate card, and all cards are again revealed at the same time.
The poker planning process is repeated until consensus is achieved or until the estimators decide that agile estimating and planning of a particular item needs to be deferred until additional information can be acquired.
Most teams will hold a Planning Poker session shortly after an initial product backlog is written. This session (which may be spread over multiple days) is used to create initial estimates useful in scoping or sizing the project.
Because product backlog items (usually in the form of user stories) will continue to be added throughout the project, most teams will find it helpful to conduct subsequent agile estimating and planning sessions once per iteration. Usually this is done a few days before the end of the iteration and immediately following a daily standup, since the whole team is together at that time anyway.
Simple: go to PlanningPoker.com. Mountain Goat Software helped develop that website to offer it as a free resource to the agile community. A product owner, ScrumMaster or agile coach can log in and preload a set of items to be estimated. A private URL can then be shared with estimators who log in and join a conference call or Skype session. Agile estimating and planning then proceeds as it would in person.
Use our recipe for integrating the planning process with your Microsoft 365 to maker your data stay with you.
Absolutely. Teams estimating with Planning Poker consistently report that they arrive at more accurate estimates than with any technique they'd used before.
One reason Planning Poker leads to better estimates is because it brings together multiple expert opinions. Because these experts form a cross-functional team from all disciplines on a software project, they are better suited to the estimation task than anyone else.
After completing a thorough review of the literature on software estimation, Magne Jørgensen, Ph.D., of the Simula Research Lab concluded that “the people most competent in solving the task should estimate it.”
Second, a lively dialogue ensues during poker planning, and estimators are called upon by their peers to justify their estimates. Researchers have found that this improves estimate accuracy, especially on items with a lot of uncertainty as we find on most software projects.
Further, being asked to justify estimates has also been shown to result in estimates that better compensate for missing information. This is important on an agile project because the user stories being estimated are often intentionally vague.
Additionally, studies have shown that averaging individual estimates during agile estimating and planning leads to better results as do group discussions of estimates.
Burndown Charts offer a simple, visual representation of where you and your team are on a project, and whether you are on track to deliver it.
They are commonly used within Agile Project Management, and they measure the progress of a project by plotting the tasks that need to be completed against the time available to deliver them.
They can be a powerful tool for showing work completed, but they are less effective at giving a clear picture of work that's in progress or only nearing completion
Burndown Charts provide an at-a-glance view of a project's progress.
Melissa is sitting in her new Manhattan office, with spectacular views over the Hudson River, but she can't enjoy it on this evening as she stares anxiously at her computer screen.
She runs a fast-growing tech startup, and is aware that renting offices in the heart of New York is a stretch for her budget. But the company is doing well. In fact, it has just landed a major new software contract. It's a deal that could establish her company in the market.
Melissa is worried that the time frame for delivery is incredibly ambitious, and she's not sure if her team can meet the deadline.
Part of the answer to Melissa's headache could be to use a Burndown Chart. It is a clear and simple graph that maps the work that's left to do on a project against the time that you have to do it in.
In this article, we'll explain how to create and use Burndown Charts, the pros and cons of using them, and how they fit within Agile Project Management .
To understand Burndown Charts, you first need to understand some of the principles behind Agile Project Management. As its name suggests, Agile is a way of managing projects in a flexible, focused and responsive way.
While there are still clearly defined goals, Agile teams are more self-directed and less tightly led by their project leader than traditional development teams are. Project requirements are often developed just before work starts on a piece of functionality, there is a focus on user testing and customer feedback, and there is an emphasis on constant assessment and reassessment of the scope and direction of a product or project.
Development teams normally work in short bursts or "Sprints," typically two to four weeks long, to deliver tangible progress on their part of the project, often developing working releases of a product or a piece of software. They may use "User Stories " to plan work, and to see what is required and how to achieve it from the end user's perspective.
Teams will also use Scrum meetings and Kanban Boards. Scrums are quick, stand-up meetings, normally held daily, that allow teams to collaborate, listen and discuss progress, achievements, obstacles and support. Kanban Boards are a way of visually showing the status of projects due to be delivered during the Sprint.
Burndown Charts are a visual tool that you can use alongside your Scrum meetings or Kanban Boards. They were invented by software developer Ken Schwaber in 2000, to give teams a simple way of plotting hours-of-work or story points remaining on a project against the time available.
They show the "burndown" for each individual Sprint (which helps team members to see the progress that's been made during it) or for the project as a whole, which allows the team to see at a glance whether it's behind or ahead of schedule.
They can also be used to show "burn-up" (where progress is slower than expected) or days that have been "burned" (again where progress has not been as you might have wished). They can also be adjusted to show when a project or task has expanded or been extended.
How you measure progress on your Burndown Chart is, naturally, going to depend on what your project is and the type of team you manage.
Let's look at how it might work by returning to Melissa in her Manhattan office...
Melissa wants to track progress daily to ensure that her project's very demanding deadlines are met. To do this, she takes charge of an Agile team, which has daily Scrum meetings to discuss what needs to be achieved in the current Sprint.
These tasks can be expressed as story points , which indicate the time and effort required to complete tasks. The team uses a Kanban Board to manage the project's flow, and updates it after each Scrum meeting to show the number of story points delivered that day. (A story point is only delivered when the project or user story that it belongs to has passed quality assurance successfully.)
To create her "Project ABC" Burndown Chart, Melissa shows the number of story points on the vertical axis of her chart, and the number of Sprints along the horizontal. See figure 1, below.
You don't have to use story points and Sprints as your measure. For example, you could swap story points for a number of tasks on the vertical axis, and, on the horizontal axis, you could swap Sprints for the number of days you have to complete those tasks.
However, you would have to define clearly what you mean by "tasks" to measure what has been completed accurately.
Burndown Charts are also commonly used to track the progress of individual Sprints, with the work to be done plotted on the vertical axis, and the number of days of the Sprint marked along the horizontal axis.
On this chart, Melissa can plot progress from her starting point of 240 story points. Her aim is to complete the project within six Sprints, or an average of 40 points per Sprint. If she succeeds in doing this, the chart will simply show a diagonal straight line down from 240 to 6, as in figure 2, below.
In reality, of course, projects rarely run as smoothly as this, and this is where a Burndown Chart can come into its own. Figure 3, below, shows the actual Sprint progress of Melissa's Agile team.
The chart shows that, while things went well during the first two Sprints, the number of story points to complete actually increased between Sprints two and three, before momentum was regained from Sprint three onwards.
There could have been a number of reasons for this: a key team member being off sick during that Sprint, the Sprint proving to be more difficult or complex than anticipated, or perhaps the client changing the scope of the project. The important thing is that Melissa and her team will have been able to see that progress was being delayed, and take appropriate action.
The main benefit of Burndown Charts is their simplicity: they are an easy-to-follow visual representation of what your Agile team has achieved, what it has yet to achieve, and whether it is on target to meet its deadlines.
They can alert you quickly to any potential problems or bottlenecks . If a chart shows a plateau, it gives a clear indication of where people need to put in extra work to bring a project back on track.
Burndown Charts can also be a useful motivational tool. They show your team what's still to do, but also how much it's successfully completed.
But they do have some weaknesses. For example, they only show what work has been completed, not what task or story point is in progress and how close that work is to completion. You should be covering this element in your regular Scrum meetings, but this highlights that a Burndown Chart only provides part of the picture.
Burndown Charts can lead to over-heightened expectations. If you're expecting your Burndown Chart to run in a neat, straight line – and are aggressively managing your team's performance accordingly – there may be a risk of team members becoming disgruntled or demotivated, especially if they feel that the chart has become a "stick" to be beaten with, or that they are constantly under the performance microscope.
Often, there can be a plateau midway through a project, when a lot of the most complex elements are being completed, and then an acceleration to the finish at the end. You need to recognize that, and factor it into how you manage your team and your project. Again, you can address these issues during Scrum meetings.
It is important not to become overly reliant on your Burndown Chart, and to use the whole range of your project management skills .
You get a SharePoint lists model ready to import into one or several Microsoft Team Sites and a PowerApp for managing sprint estimates burndown charts. The solution is backed by a PowerShell script which can be hosted where you like.
Everything comes with a recipe on how to implement and extend the solution.
This recipe is using functionality made available by the www.hexatown.com framework for server side data processing based on PowerShell hosted on your own servers. No data processing will be done outside your tenancy. No internet connectivity is required for implementing this. Only services specific access is required.