While Scrum’s target is in product development, Scrum often gets used within project management. The goal of a project is to create a unique product, so Scrum shouldn’t have too many issues being modified for a project – although it may require some additional considerations. Before choosing to use Scrum for a project, it may be worthwhile to consider a more robust project focused approach such as DSDM; DSDM is Agile and probably will suit most project needs better than Scrum.
Outlined below are various stages of the project life cycle in Scrum and some additional things to consider. Please note that this does not include all of the Scrum meetings or ceremonies. This is intended to be a project flow overview and doesn’t consider the Daily Scrum or the Retrospective in that flow.
*Learn who would be the Project Manager in Scrum and learn about the Scrum Master Role.
A Scrum Project Life Cycle Flow
Kanban/Scrum Board Tool Set
Pre-Sprint
Project Charter
This may also be known as initiating the project.
The Project Charter is a document that lays out a basic framework of the project and is used to declare the existence of a project and grant it permission to proceed with project activities.
The composition of the Agile Project Charter may vary by organization but in general, it should contain a high-level existence of what the project is doing and what will make the project successful. Accompanying this document it may be a good idea to create a more visual document just showing the project goals so that it can be looked at quickly and easily to get a general idea of the direction of the project.
A Scrum master needs to be selected for the team as well, and they can be identified within the Project Charter. If the customers have not chosen a representative, The Product Owner, this should be done now and identified within the Project Charter.
Requirements Gathering
This would fall under the planning process group.
You start getting some of the initial details and larger features of the unique product you are aiming to create. You don’t need them very detailed right now, but you want to gather some tasks to create the initial Product Backlog.
It may be a good idea to also figure out who is handling the release of the increments. Scrum itself doesn’t outline dedicated release planning. If the project team is to be responsible for releases this will need to be known and handled as tasks during the Sprint. So as you are gathering requirements to work on, there is also a deeper fact-finding component where you need to identify responsibilities for the project team to begin building the Scrum Development Team with needed skills.
Product Backlog Creation
This would also fall under the planning process group.
A continuation of the Requirements Gathering, you take your core tasks and start to break things down into understandable chunks. If you are using User Stories, this is a good time to prepare them – but whatever standard you are using to create a backlog, now is the time to do it.
This may require some additional information from stakeholders both on and off the development team to help breakdown some of the requirements. You also carry out any final tasks to help ensure the Sprints will proceed smoothly.
By the end of the creation of the Backlog, and before you start the Sprints, you want to ensure that you have held a project kick-off meeting (Should You Hold a Project Kick-Off Meeting in Scrum?) and received formal approval of the Product Backlog. The Product Backlog represents your fluid and evolving plan.
Additional Books on Scrum
- Scrum: The Art of Doing Twice the Work in Half the Time
- Scrum Mastery: From Good To Great Servant-Leadership
- Scrum: The Ultimate Intermediate Guide to Learn Scrum Step by Step
Sprints
Sprints tend to be made of all five project management process groups as defined by the Project Management Institute. You have initiating, planning, executing, monitoring & controlling, and a Sprint closing in each Sprint.
The iterative cycle of Scrum it is where most of the project work will occur. Each Sprint a part of the whole project will be released in an increment. Each of the stages below will be repeated until the project is completed.
Product Backlog Refinement
Product Backlog Refinement can really occur at any time, but you want to ensure it is up to date and prioritized before a new Sprint is planned. During this stage, you need to ensure the Product Backlog is properly prioritized and the top items have enough known detail to be completed.
Sprint Planning and Sprint Backlog Creation
Often called ceremonies in Scrum – Sprint Planning is a meeting. You flesh out the details of the top items in the backlog. You may need to meet with stakeholders to gain more details to your items.
During this meeting, you will create the Sprint Backlog, a list of all the items the development team plans to complete in the current Sprint. This contains the Sprint Goal. The Sprint Backlog can be adjusted and changed during the Sprint but generally, you want to avoid that as much as possible.
Product Development
Create the items in the Sprint Backlog. This is where you work on the main objectives of the project by building the intended product or project output. Product Development will form the bulk of activities during the iteration cycles or Sprints. It falls under the Executing process group as defined by PMI.
Every day during a Sprint, according to the Scrum Guide, you will hold a Daily Scrum. The Daily Scrum is a 15-minute daily meeting for the Development Team to discuss their current progress and any issues they are encountering. The Daily Scrum is a part of the Product Development phase.
Sprint Review
At the end of the Sprint, a piece of the product is put up for inspection. They will demonstrate this piece for the customer of the project and the customer may choose to accept or reject it. Ideally, the customers would provide constructive feedback to help guide them through the next Sprint.
It is at this time you measure the current state of the project to determine if the project is going in the correct direction. You evaluate the business goals against the product. You determine if the project is still relevant and needed. This is a huge part of monitoring & controlling the project.
After the Sprint Review, you would typically hold another ceremony called a Sprint Retrospective. It is a bit like a lessons learned meeting for the Sprint.
Outside of the Sprint/ Congruent to the Sprint
Incremental Releases
Scrum doesn’t really cover much about the release. It is pretty much left up to the product owner to figure that out within the organization. If a piece of the increment is potentially releasable, the Product Owner needs to work with the customer on whether to release it and how to release it. If the increment is capable of standing alone or merge with an established product than releasing should be considered. This is where the early delivery of value and the ability to gain feedback from the market comes into play and it is an important part of Scrum.
Project Close
Eventually, your project will be completed. When that happens may vary by your product and schedule. Every Sprint through Scrum is a possible “last Sprint” with some projects, other projects you know about how long and how many Sprints roughly it may take assuming no huge changes. The decision on whether the project is viable for another Sprint should be made during the Sprint Review at the latest.
Weigh the original objectives or the business goals of the project against what was achieved. Most benefits may not be immediately recognizable, although the incremental release structure should have been in place and benefits should be accruing by the time the project is in a closing state.
During closing, it can still be beneficial to hold a lessons learned meeting. You are holding a Sprint Retrospective (after the Sprint Review) each Sprint to get better within your Sprints, now it is time to look for ways to improve in your next project and celebrate your successes in the closing project.
Reflection
That is a high-level overview of a project life cycle in Scrum. I still recommend DSDM here instead of Scrum as the above project flow is very close to how DSDM handles it.
Sources:
Project Management Institute/Agile Alliance, (2017). Agile Practice Guide. Independent Publishers Group/Project Management Institute
Project Management Institute, (2017). A Guide to the Project Management Body of Knowledge, 6th ed. Independent Publishers Group/Project Management Institute
Share this:
Categories: Agile, Leadership, Project Management, Scrum
Agile-Mercurial 
2 replies »