This article shares recommended best practices and processing tips for planning and managing scrum backlogs, sprints, and projects in the Project Management Framework.

Topics include:

This article shares recommended best practices and processing tips for planning and managing scrum backlogs, sprints, and projects in the Project Management Framework.

Topics include:

Starting New Projects

Grooming the Backlog

Planning a Sprint

Adding Tasks to User Stories

Conducting Sprint Reviews

Optimizing Sprint Burndown

Working with Epics

Working with Themes and Milestones

Other Scrum Project Articles

Starting New Projects

Before You Can Begin

• A Product should exist.
• A Release should exist.

Starting Steps

• • Populate the product backlog with user stories. This task can be performed before or after you create the project.
  • Create a new Scrum project
  • On the entry screen, associate it with a product, release, and a backlog.
  • Use the Manage Resources Action to enter your project resources to add the project to the dashboard of those resources.

• • Enter the resources individually into the grid or add them as a group from a particular organization division or unit.
• Groom your backlog to prepare user stories in an Open-Ready status for populating the project sprints.

Grooming the Backlog

Product backlogs provide the user story content for project sprints. Grooming the backlog is an ongoing process. When consistently performed, grooming creates a prioritized list of planned user stories ready for you to include in sprints and builds a backlog of stories for future sprints.

PMF provides tools that are designed to perform grooming tasks that are described in the article Working with Scrum Backlogs including:

• Status Monitoring
• Order and Ranking
• Setting Dependencies
• Bulk Processing

When grooming the backlog:

• Set a team goal to make sure that there are at least two sprints worth of work in an Open-Ready status for your sprint planning sessions.
• You can associate a story with a project. This allows you to start planning items for a release.
• When sizing a story, review the description and acceptance criteria to make sure there is enough detail. If there is, determine the size of the story and enter story points in the Story Points field and set the status to Open-Ready.
  • Tip: for guidance on how to size user stories, refer to agile methodology websites and articles like: http://www.agileweboperations.com/estimation-user-stories-story-points-abstract-size-measure
• When there is not enough descriptive detail to size a story, set the status to Pending-Details.
• Rank and re-order the stories based on current business priorities.
• Set dependencies to other items in the backlog or an existing sprint.
• Move items into the next active sprint using the Bulk Process option.

Planning a Sprint

Before You Begin

• The backlog has been groomed so that it contains user stories for sprint consideration that are in Open-Ready status
  • the story description and acceptance criteria have been entered and agreed upon
  • the story points are entered

Planning Steps

• • Display the Details tab of the project to view the team Velocity for the previous sprint. This establishes a guideline for setting story points for the next sprint.

• • Add a new sprint to the project tree using the action.
    • Enter the sprint name, objectives and target dates
    • Enter the number of resources and estimate hours are entered
    • Set the status to Pending-Start
  • Click to open the product backlog.
  • Using the previous sprint velocity as the guideline, review the stories that are in Open-Ready status to determine which stories you want to pull into the sprint to meet your target velocity.
  • Click on the backlog.
    • Select the stories that are ready to move to the sprint.
    • Select the Move Item action, select the target project and sprint.
    • Click Process Work to move the stories to the sprint.
  • Return to the project, refresh the Tree tab and expand the sprint to view the stories that you moved to the sprint.
  • Double-click the sprint and set the status field to Open-InProgress to lock-in the estimated velocity for the sprint.

The sprint is ready for Task Planning.

Adding Tasks to a User Story

Before You Begin

• The sprint Status has been set to Open-InProgress and a velocity estimate is entered.

Planning Steps:

• Open the project Tree tab to expand the sprint display the user stories.
• Double-click the first user story.
• As a team
  • read the details
  • discuss and agree upon what work needs to be done to complete this story and estimate in hours how long it will take
  • add the acceptance criteria
• Right-click the story and select the action.
• Enter the description and set the hour estimate.
• Continue to add tasks for development, testing, documentation and other types of tasks needed to complete this user story.
• Repeat to add tasks to the other user stories in the sprint.

Conducting Sprint Reviews

Before you Begin

• The tasks for the user stories in the sprint are in a Resolved-Complete status.
• The user stories are in a Pending-Verificationstatus.
• A new sprint in  Pending-Start status has been added to the project.

Review Process

• Open the first story in the current sprint so the team can review the details and acceptance criteria.
• Team members responsible for the user story demonstrate the functionality that was developed.
• The product owner determines if the functionality as demonstrated meets the acceptance criteria.
• If the story passes acceptance, it is approved and resolved.
• If the story does not pass acceptance, the story can be rejected and moved to a future sprint.

Optimizing Sprint Burndown

A major goal of sprint planning is to schedule the right amount of work into the sprint but sometimes too much or too little work is pulled into a sprint. In this case the team needs to either add or remove tasks. By monitoring the remaining effort of a sprint in a burndown chart, you can visually see on a day-to-day basis whether or not your sprint is progressing as planned and take remedial action.

In PMF the estimated work remaining in the sprint is calculated daily and graphed into the Remaining Effort Burndown chart that visually indicates whether you are burning up or down during the sprint..

During Sprint Planning

• Enter sprint start and end dates to set the date range of the burndown chart
• Enter the number of resources and estimated hours per resource.
  • These values along with the sprint length determined by the date range calculate the sprint capacity in hours.
  • Sprint capacity determines the starting point of the Optimal Trend line on the chart.
• Move stories in Open-Ready status from the backlog to the sprint.
• From the Project Tree, double-click the sprint and set the status to Open-InProgress.
  • This sets the Target Velocity for the sprint (sum of story points from all user stories in the sprint)
  • It also starts including the user stories, tasks, and bug items for the sprint in the nightly processing cycle that gathers burndown data

After Sprint Planning

• Complete task planning for each user story by setting a target and remaining effort as soon as possible.
  • These efforts are written to a burndown data table which is read by the nightly processing agent.
• Update the target dates and effort hours for tasks, bugs and issues on a daily basis so that chart reflects the true burndown rate.
  • For individual tasks
    • From the Tree tab, double-click the task and update the Hours Remaining and Additional Hours Worked fields in the pop-up window.
  • For multiple tasks
    • • Click the Work tab on portal to display the user's worklist.

    

    • • Click Dates & Efforts to display all tasks for the current project.
      • Double-click a row to open fields where you can update the priority, name, target start/end date, actual start date, and the additional/remaining hours for a task, bug or issue.

    

Working with Epics

It’s common practice in scrum to keep user stories small so the team is able to complete the implementation of a story in a single sprint.  However, it’s also common to organize stories into larger categories called Epics.

Think of epics as collections of user stories organized by a naming value. The value represents a significant amount of work that is too large for a single story. They are broken down into smaller manageable units of work that can be completed in a single sprint or across multiple sprints. PMF includes an optional Epic field on user stories that allows you to flag and track these collections by a name.

For example, user stories like these are candidates for epics because of the number of components and the order in which those components are developed:

• Customizable End User Desktop – As an end user, I want to be able to customize my desktop so I can get my work completed more efficiently based on my work patterns.
• Visual Task Management – As an end user, I want to manipulate my tasks from a screen so I get a complete view of my work
• Guides Application Entry – As an end user, I want the system to guide me through the application process so I can minimize training.

Adding Epics to Stories

Epics can be added, updated or removed from user stories by:

• • Entering the value in the Epic field when the user story is created.

When added, they appear before the name of the user story on the tree

• • Selecting the Update Epic action from a single user story

• • Selecting the Update Epic action as the bulk processing option

Tracking Epics

You can track and view the stories associated with Epics in a project by selecting User Stories by Epic located in the Additional Reports section of the Reports tab.

Working with Milestones and Themes

In PMF, milestones and themes represent higher level values that span an entire project and can be used to communicate direction and alignment of project initiatives and deliverables. They are entered as part of the project detail and then associated with sprints and user stories. This allows product managers and scrum teams to validate whether or not the scope and breadth of the project and the sprints/user stories are aligned with key delivery points and corporate initiatives.

Milestones are data values that can be associated with a target date to align sprints and stories with important project stages or checkpoints in a project.

Examples of milestones values are:

• Initial Demo & Review
• Pilot Release
• General Release

Themes are data values that represent logical groupings of features that are typically of interest to the end user community and represent high level department or corporative initiatives.
Examples of theme values are:

• Improved User Experience
• Simplified Navigation
• Improved Customer Self Service
• Paperless Processing

Tracking milestones and themes

• • You can view a list of the sprints and user stories associated with project themes and milestones from the Milestones and Themes section of the Details tab of a project display.

• • Click a Theme or Milestone link to display the list of associated items with the name, ID, Category (sprint or user story), target start and end dates, remaining effort and status.

• • Milestones are tracked in the Items by Milestone and Status report located in the Project Summary Reports section of the Reports view of the portal.

Note: Milestones and themes are exposed properties that you can also use in custom reports.

This article links to following articles about working with scrum projects in the PMF 6.1.1 release.

Creating Scrum Projects

Adding Scrum Sprints and User Stories

Working with Scrum Backlogs

Return to About the Project Management Framework to access all PMF articles.