Introduction
In this session, I will demonstrate how traditional tools, such as Microsoft Project, can provide full support for Scrum/agile projects. You will see how you can leverage your existing investment in Project Management tools, augmented with an agile management framework that supports the rituals, to effectively manage agile projects. This approach ensures a consistent view across all projects, independent of delivery approach.
But first, a brief definition of Scrum/agile project management as used in this paper. First and foremost, this definition is consistent with how the industry defines these project delivery approaches.
As defined by Wikipedia,
“Scrum is an iterative and incremental agile software development framework for managing product development. It defines “a flexible, holistic product development strategy where a development team works as a unit to reach a common goal”, challenges assumptions of the “traditional, sequential approach” to product development, and enables teams to self-organize by encouraging physical co-location or close online collaboration of all team members, as well as daily face-to-face communication among all team members and disciplines in the project.”” (Wikipedia, Scrum (software development), 2014).
and
“Agile software development is a group of software development methods in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development, early delivery, continuous improvement and encourages rapid and flexible response to change. It is a conceptual framework that focuses on frequently delivering small increments of working software.” (Wikipedia, Agile software development, 2014).
In fact, this paper will expand on these definitions and define a process that ensures a repeatable management process that is consistent with Scrum/agile development methods, while at the same time expanding on the traditional use of the traditional project management tool to maintain the all-important user story and a flexible iterative development approach.
This paper reviews a Scrum/agile management template that ensures that the key agile rituals are executed in a consistent manner. It does this using a sprint/iteration framework for managing the user stories for delivery in releases and sprints using a traditional project management tool. In essence, we will break the stereotype that a traditional project scheduling tool—in this case, Microsoft Project—is only suitable for traditional sequential development. The Scrum/agile template provides the support needed to successfully deliver iterative and incremental Scrum/agile projects using the tools already entrenched in your organization.
There are two very significant benefits of using existing tools for Scrum/agile projects. The first is the ability to leverage existing licenses, training, and experience; secondly, by managing both traditional and agile projects with the same tools, support for integrated project portfolio management is provided, effectively allowing for reporting of all projects to senior management in a single, integrated dashboard.
The Challenge: Disparate Tools
Today, many companies are using disparate tools for managing agile and traditional projects. This is highly inefficient on many fronts:
- Purchase and licencing costs for multiple tools
- Training costs and knowledge gaps for project managers
- Separate repositories for project data
- Effort to produce organizational-level reports
- Enterprise resource management difficult across multiple tools
- Team members record time across multiple systems
The reason most organizations implement separate tools for agile and traditional project management is that agile is defined as a totally different approach to delivering projects, requiring a specialized set of tools to support the unique agile approaches, such as product backlog management; iterative, time-boxed development; and adaptive delivery management.
In the next section of this paper we will explore whether agile is a significant and revolutionary approach to successful project management requiring specialized tools, or more of an evolutionary improvement than can be supported by traditional tools.
What Are the Requirements for Successful Agile Delivery?
In this section, I will review the requirements for agile delivery and compare them to traditional delivery to identify the similarities and differences between these two delivery approaches. It is critical that these similarities and differences are understood before we explore how a traditional management tool can be used to support an agile project.
Agile requirements were originally defined by the Agile Manifesto, and the twelve principles of agile software and were further developed and refined by the Scrum Alliance. For the sake of brevity, in this paper we will defer to the definitions from Wikipedia presented in the Introduction.
For the purposes of this paper, traditional project management requirements are based on PMI's A Guide to the Project Management Body of Knowledge (PMBOK® Guide) most specifically the 10 Knowledge Areas.
| Traditional (PMBOK®) Versus Agile Development Requirements | |
| PMBOK® | Agile |
| Project Integration Management | |
| Project Integration Management provides the overall structure under which a project is to be delivered and is heavily based on a project charter, project plan; IT also defines the processes for managing and controlling to the project plan and performing integrated change control to ensure that all work is approved. | Agile projects have project vision statements, release plans, iteration plans, daily standup meetings, backlog management, and most significantly stringent management of the stories to be completed in an interation. |
| Project Scope Management | |
| Project scope management is focused on defining the project scope during the beginning of the project and then rigorously managing the scope for the duration of the project. | One of the reasons that agile projects are being adopted so widely is the idea that agile supports evolutionary scope, defining it as needed to support individual iterations. But, on deeper analysis, agile simply defers rigorous scope management until the iteration is planned. Agile still defines a high-level scope at the project vision, a medium-level scope at the release, and a detailed scope at the iteration. |
| Project Time Management | |
| Project time management is focused on finalizing a detailed work breakdown structure, estimating activities, defining dependencies, and creating a detailed project schedule. | Agile projects develop a story point for each story and develop iteration plans based on the available capacity (velocity) for each iteration. |
| Project Cost Management | |
| Project cost management is focused on identifying the project costs and developing the project budget. | Most agile methodologies are very quiet on cost/budgets. However, most if not all organizations have a focus on cost management, so some level of cost management will be required on agile projects. |
| Project Quality Management | |
| Project quality management defines the processes to be followed to ensure that quality assurance (doing the right things) and quality control (doing things right) are performed on the project. | While agile doesn't focus on the terms quality assurance and quality control, agile is very focused on delivering high-quality results with built-in features for peer reviews (pair programming) and testing (test-driven development, definition of done). |
| Project Human Resource Management | |
| Project human resource management defines the processes for building the team and ensuring effective team composition and performance for the duration of the project. | Agile principles do not focus on team management, as the projects are anticipated to be of relatively short duration with very little change in the team composition. Agile teams are defined as self-managed teams of peers and therefore self-manage the human resources components to ensure a high-performing agile team. |
| Project Communications Management | |
| Project communications management plans and manages the project communication to ensure that the appropriate messages are delivered to all project stakeholders at the right time using the right method. | Agile projects are very focused on communication, although in an informal method. Agile communications focus on “information radiators,” which should be easily accessible to any and all stakeholders as needed. |
| Project Risk Management | |
| Project risk management provides a defined process for identifying, validating, and planning risk responses and dealing with project risks. | Agile is often believed to not require formal risk processes, as the short-term planning, one iteration at a time, supposedly allows for built-in risk management. However, agile does address risks as part of the daily standup and has the provision for capturing risks as stories to eliminate code smells, refactor code, and develop exploratory spikes, all of which are risk-elimination techniques. |
| Project Procurement Management | |
| Project procurement management defines the processes for identifying project components that must be procured and then planning and managing the procurement process through a complete life cycle. | Agile principles do not explicitly call out procurement as an agile activity. Therefore, in the absence of specific agile procurement policies, traditional methods are a possible candidate. |
| Project Stakeholder Management | |
| Project stakeholder management is focused on identifying all project stakeholders and establishing the processes to ensure ongoing stakeholder satisfaction. | Agile explicitly defines the product owner as the key stakeholder and has the expectation that the product owner will isolate the project team from the other project stakeholders. |
Why Do Agile Projects Use Different Tools?
One of the main reasons many agile projects use different tools is simply to help differentiate them from traditional projects. That said, agile tools are often designed from the ground up to support agile techniques such as planning and tracking of epics, stories, themes, defects, tasks, tests, and issues. One of the key distinguishing features of an agile tool is that most are all-encompassing, from story management to iteration planning to testing and defect management.
Because agile projects are delivered in a series of short iterations, many practitioners suggest that the integration of the entire planning, development, testing, and management process is the major argument for a dedicated tool. Almost any development process includes activities such as:
- Requirements management
- Planning
- Tracking
- Quality assurance
- Feedback gathering
In addition, many agile tools have built-in process support to help organizations accelerate the adoption of agile with guidance to help beginners complete each step of the agile development process—from story development to project, release and sprint planning, as well as progress tracking, testing, and story completion.
Definition of an Ideal Agile Tool
For the sake of objectivity, I will take my definition of an ideal agile tool from the internet white paper, “Agile Tools. The Good, the Bad and the Ugly”(Dubakiv & Stevens, 2015).
Modern agile project management software combines common activities and provides an open Application Program Interface (API) for advanced integration. It powers:
- User stories and epic management
- Backlog prioritization
- High-level resource planning and low-level iteration planning
- Progress tracking via virtual burn-down charts, task boards, and daily progress
- Test management via test case support and integration with automated testing tools
- Bug management via bug tracking support and integration with external bug tracking tools
- Customers’ request management via help desk functionality or integration with third-party tools
While this definition does come from an agile tool vendor, it is representative of the depth and breadth of the agile tool market and fairly represents the high-level requirements for an integrated agile tool.
Agile Template Using Traditional Project Management Tools
The agile template is based on extending the functionality of the traditional project management tool to follow an agile process where the story and the product backlog are the focus within the tool, rather than the schedule, as it would be in a traditional project.
The focal point of the template is the product backlog, shown here:
Figure 1: Product backlog view
The product backlog follows a defined process for story time/backlog grooming as defined in the following flow chart:
Figure 2: Agile process flow chart
The next key feature of the template is that it contains a Scrum/agile management framework that provides guidance to the project team as they plan and execute the agile rituals that are so critical for ensuring that projects are effectively managed. It is adherence to these rituals that differentiate well-run agile projects from disastrous, chaotic ad hoc software development based on just iterative development without any discipline.
The management framework starts off with the all-important product vision/discovery session, in which the business defines the objectives of the project.
The Project Vision:
- Establishes the release strategy/story map;
- Selects the agile parameters for release/sprint durations;
- Identifies the development techniques to be applied; and
- Defines the desired results.
Figure 3: Product vision process guidance
Next, the management framework defines a sprint Zero to establish the project environment. While this sprint Zero may not be required in organizations with established processes, taking the time to execute a sprint Zero ensures that the development tools, team spaces, and team norms are established before the “clock starts” on developing implementation-ready code.
Figure 4: Sprint Zero process guidance
With these one-time foundational activities completed, the framework then goes into the repeatable rhythm of releases and sprints. The framework recognizes that there are key activities required at the beginning of each release. This is required to formally plan the release and ongoing activities throughout the release to manage the product backlog to ensure a ready supply of user stories for future sprints. Similarly, the framework defines the key activities that must take place within each sprint, including the daily Scrum, publication of key progress charts (burn-down charts), and the critical sprint review and retrospectives that take place at the end of each sprint.
Figure 5: Release planning process guidance
The key benefit of this management framework is that it provides the gentle nudge we need during delivery to stay true to Scrum/agile principles while still allowing all the benefits of “just-in-time” planning and development that first drew us to trying agile in the first place.
This framework supports the management of the product backlog in the framework of established releases and sprints, as well as provides support for unassigned/incomplete user stories. This framework replaces both the product backlog and sprint backlog cork boards and provides an innovative method for managing the story type, priority, status, and story point estimates as the story evolves from a preliminary placeholder to “story complete” scheduled for a sprint and release development.
Using the Sprint/Iteration Framework
A typical story life cycle would be to initially record the story name (in the task name column), set the story flag to “Yes,” and set both the Release and Sprint to 99.
Figure 6 – New Story Creation
During story time/backlog grooming, the product owner would review all new stories and determine that each story is appropriate for the project by setting story status to “not started” or “rejected.”
Figure 7 – Setting Story Status
As the product owner and/or subject matter experts get time to add details to the story, the status is changed to “in progress” and the story type and story priority are added to the backlog. A story may spend a considerable amount of time in this status as the business refines and evolves the story.
Once the business is satisfied with the story, the status is marked “story ready,” which is the indicator that the product owner should do a final review.
The product owner does one final approval of the story and either sets the status back to “in progress,” if it is not ready for development, or sets it to “story approved.”
Figure 8 – Approved Story
This is an indicator to the project team that they should review the story and develop the story point estimate for the story. Once the estimate is provided, the team would mark the story as “story points complete.”
Based on release plans and story priority, the story will get scheduled for a release and/or sprint by setting the release and sprint fields and updating the sprint ready flag.
At this point, the story is ready for assignment to a team member and scheduled for development in the appropriate sprint by setting the assigned to sprint flag to “yes.”
Figure 9 – Product Backlog
Once a story is scheduled for development in a specific release/sprint, the story is moved into the appropriate section of the overall project plan using the Scrum Gantt chart where resources are assigned, work estimates are assigned (this is optional), and actual time is tracked.
Figure 10 – Sprint Plan
Process support/validation has been built into the template using customized ribbons that present the filters, views and reports we use to ensure that the agile processes and flow chart are being followed. The first of these is the agile analyzer, which has three groups: agile views, story maintenance, and story validation.
Figure 11 – Agile Analyzer Toolbar
Agile views provides ease of access to the three custom views required for managing an agile project. While these views will be used heavily in the delivery of an agile project, an additional selection is included to provide access to the complete set of views available in the tool.
The Scrum Gantt view is used during project delivery to manage both the agile planning activities and daily sprint execution processes. Actual time tracked and updated estimates to complete can be viewed and managed in this view.
The story list is used by the product owner and other business Subject Matter Experts (SMEs) to manage the stories that will be developed by the project.
The product backlog is used by the product owner and the project team to also manage the stories, but within the context of the releases and sprints.
Story maintenance has a number of validation checks to ensure that the stories are being developed in a way that is consistent with the process flow.
New stories: This will highlight all stories that do not yet have a story status assigned. This view is intended to be used by the product owner to validate that new stories are appropriate for the project.
In progress: This will highlight all stories that have a story status of “in progress.” This view is intended for business SMEs to be able to quickly identify which stories require additional details to make them complete and ready for allocation to a sprint.
Story ready: This will highlight all stories that have a story status of “story ready.” This view is intended for the product owner to review stories and validate that they are complete and ready to be passed to the project team for determination of story points.
Story approved: This will highlight all stories that have a story status of “story approved.” This will allow the project team to identify all the stories that require a story point estimate to be developed.
Story Point Complete: This will highlight all stories that have a story status of “story point complete.” This will be used by the product owner to review the complete story, including the story point estimate, to confirm that the story is ready for assignment to a sprint, at which time the sprint ready flag is set.
Sprint validation has a number of validation checks to validate that the story status is consistent with the supporting information for the story. For example, a story that is “in progress” should have a story type and priority.
No story type: This will highlight all accepted stories (story status set and/or release/sprint set) that do not have a story type assigned.
No story priority: This will highlight all accepted stories (story status set and/or release/sprint set) that do not have a story priority assigned.
Release/sprint not set: This will highlight all sprint ready stories where the release and/or sprint number has not been assigned (i.e., not 0 or 99).
Not sprint ready: This will highlight all sprint ready stories where the story point is zero and/or the story status is not “sprint point complete.”
Agile Reports
This ribbon has three groups or reports: agile dashboards, current sprint, and releases and sprints.
Figure 12 – Agile Report Toolbar
The agile dashboards provide three reports specifically designed to support overall management of the agile project.
The project dashboard provides a high-level view of the project, allowing you to view project completion at the project and phase (outline level 1) levels. It also provides lists of upcoming milestones and late tasks.
The cost dashboard provides a high-level view of the project budget, allowing for the review of actual and remaining costs at the deliverable level of the WBS.
The resource overview provides the details necessary for effective resource management so you can ensure that all assigned resources are being properly utilized.
Figure 13 – Agile Project Overview Report
The current sprint provides four traditional agile reports intended to be shared with the team during the daily Scrum meeting. There are burn-down and burn-up charts for both stories and work, allowing the project to select the information radiator appropriate for the management style being applied. These reports are based on all stories scheduled for work within a two-week window of the current date (based on a two-week sprint).
The story burn-down chart shows the progress of remaining stories versus planned stories for the sprint.
The work burn-down chart shows the progress of remaining actual hours versus project hours for the sprint.
The work burn-up chart shows the progress of week's work versus hours planned for the sprint.
Figure 14 – Sprint Burndown Chart
The releases and sprints provide the same four traditional agile reports showing all work grouped by releases and sprints. The level of detail on these report can be controlled using the “filter feature” in the reports area. The content and style of these reports is identical to the current sprint described previously, just reported over a large timeframe. There are burn-down and burn-up charts for both stories and work, allowing the project manager to select the information radiator appropriate for the management style being applied.
Benefits of the Scrum/Agile Management Framework
The management framework allows you to develop a plan for the initial stages of your project, discovery and sprint Zero following traditional planning methods where you assign resources and estimate each task and allow Microsoft Project to develop a realistic project schedule for these foundational activities in your plan. This makes these startup activities more predictable and helps you manage expectations for when the iterative development activities start. For this reason, the template for these two stages has been created to support auto scheduling, work/effort based estimating and task dependencies to support the development of a realistic plan for these critical planning activities.
The Scrum/agile management framework emphasizes the fact that there is planning in Scrum/agile, but it also helps manage the level of planning to be just enough to ensure that the project vision is established and the project environment allows for effective iterative development.
The focus of the template then changes the approach to be more agile, and supports the ongoing and iterative approaches of Scrum/agile development. Releases and sprints are scheduled as fixed-duration activities following the agile strategies developed during the planning activities. For example, releases might be scheduled for three-month durations while each sprint would be scheduled for two weeks.
Maintaining the repeating sprints follows a similar strategy as releases, where tasks are estimated and assigned to the appropriate resources.
