PractiProject

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 39 Current »

View in Atlassian Marketplace

Overview

Plan your team and resources for your sprint workload, track the Sprint Progress and view your project roadmap KPIs

  • Planning view - Plan ahead your sprint success - Now you can estimate the amount of work your teams require to complete their sprint plan During sprint planning, see if your team is over allocated or able to complete the work within the sprint time frame.

  • Tracking view - View sprint progress and risks - Different views of total time tracking (Original estimation, Remaining estimation, Logged work) of team resources. Risk assessment of the progress by time of logged work vs. sprint progress.

  • Team setup - Resources commitment and vacations - Create teams, add or remove members to the teams, copy team's composition from the previous sprint to the current sprint.·You can use multiple teams within one active sprint.

How do we ease the Sprint Planning phase

The sprint planning phase is one of the hardest phases to implement in scrum. Many teams strangle with this phase, and the outcome is often far from accurate (and these are the exact things which are later checked in the retrospective meeting).
But still, while implementing scrum in companies and reviewing different teams, we've seen some teams which actually managed this phase relatively easier than common. 

Some of challenges teams are dealing with in the sprint planning phase are:

  •       How can we select our PBI’s and how can we see if they fit in my sprint? 

  •       How do we distribute our work in a sprint? 

  •       How can we check the teams capacity?

Teams Availability and Capacity Planning:

As the first activity of the sprint planning, the team will set the potential work days available for the next sprint. This should take into consideration teams' holidays, personal vacations, or other personal obligations that will reduce personal availability for the sprint period. 
Moreover, team member may work on multiple projects (sprints) and hence may devote different amounts of time for each of them.
You can now set the availability time per each team member (their daily capacity), set the team member days off per sprint (as shown below), or set the days off for the whole team.

The teams allocated for the sprint can be either Global Teams or Board Teams.
Global teams are created centrally by an administrator and can be re-used in multiple projects and sprints (reducing the need to redefine teams over and over).
Board Teams are created and can be used in a single Board only (enables agility and the creation of dedicated sprint specific team if needed).

Sprint capacity screenshot (server version)

Sprint workload balancing

When you put the right PBI’s and tasks in to your sprint, it is time time to give them (better) estimations. Usually work items are estimated in hours or days.
To have a clear view if the number of hours you estimate are still in line with your capacity, you can use the planning panel.
By selecting the team in the panel, the capacity panel can be used to list your team resources and their current availability.
By assigning tasks to a person, the bars fill up and you get a great view on your capacity planning.

 Planned work capacity is calculated using tasks 'Remaining' field value (click for more about this).

We all strive to have all of our tasks completed within the sprint they were assigned to, however, it is not uncommon to have tasks start in one sprint and completed in later sprint(s).
When it comes to the planning of a future sprint which includes already started task(s), it is important to know exactly how much work is planned for the team based on how much work remains to be done, and not based on the estimated effort originally set for the started task(s).

With the scrum model thumb-rule in mind that for new tasks the estimated effort and remaining time are the same, and in order to provide the most accurate planning capacity for any sprint (may it contain new tasks only or already started tasks as well), Sprint Capacity Planning calculates the planned capacity based on the sprint's tasks 'Remaining' field values  (and not 'Estimate' value). This gives the sprint planner a more true view of the actual work effort that is planned for the team and team members.

Once a sprint starts, planned capacity values are locked. Any updates to the sprint's tasks 'Remaining' field values (such as with log work), do not affect Planned Work values as recorded when sprint started.
Removing a task from, or adding a task to a started sprint will update the Planned Work values however - 
When a task is removed from the sprint, the value it had in 'Remaining' field when the sprint started(!) will be subtracted  from the Planned Work capacity.
When a task is added to the sprint, its 'Remaining' field value will be added to the Planned Work capacity.

Sprint capacity screenshot (server version)

Now we will balance the load so that it does not exceed the capacity of the team and team members.

If there are number of team members for whom the load exceeds the capacity, we will go ahead and move the task back to Product Backlog so that the load will reduce and will be within the capacity of the team member.
As long as we have enough potential free time for a member we will have a green color bar indication. As we get closer to the maximum limit (90%) the bar color will be changed to yellow.
If we will go beyond the calculated capacity of the member (over 100% allocation) the bar color will be changed to red.

When all team members are set with tasks, and their capacity is fitting the potential work time set for the sprint (better to keep some reserve – it is recommended to plan no more than 90% of the potential time) we would have a plan that the team can commit to.
Personal and team commitments for the sprint plan are part of of the base pillars of scrum methodology. This allows us to move from “best effort” style into “commitment” style.
Commitment is a key factor for the team to make the plan happen and make the needed extra effort in some situations. Such team just might do the change between missing sprint (and releases) deadline to keeping the actual results same as our initial plans.

Tracking your Team's work progress

After we have started our sprint, we would like to have an overview look on our sprint work progress, completion and efforts.

You could look at your tracking mode and see the status of individual and team effort with achieving the sprint goals. 

You will see the total Original estimations (commitments) and the on-line logged work (and what still remains in order to complete the sprint commitments).

Assessing the Sprint schedule Risks

A color triangle will display the risk risk assessment of the work progress rate. If green - then the assessment is that we are as planned in respect of work logged vs. planned.

If yellow or red, then the system indicates that the individual (or the whole team), is at risk of not completing their sprint commitments and some action should be taken.

Sprint capacity screenshot (server version)

Server and cloud user manuals



  • No labels