For project managers who are training in SCRUM agile, here is a reference.
In SCRUM user stories are added to a product backlog, which are organized and prioritized by the product owner into a sprint backlog. The work that needs to be done is in that sprint backlog and is worked through and checked on daily through the daily scrum (usually conducted by a scrum master).
In traditional project management, the project manager would be responsible for planning the work to be done and would meet with stakeholders, they would also ensure the work is moving along.
Scrum Agile Methodology and Agile Software Development
- User stories (and tasks, features, etc.) are written and added to the product backlog. These can be written by the team, the project manager, project owner, or any other stakeholder.
- The Product Owner (or project manager) organizes the product backlog.
- During a sprint planning meeting, user stories are selected for design and development and implementation and prioritized into the sprint backlog by the product owner.
- The team works on the items in the sprint backlog with the Scrum Master helping to unblock team members.
- Every day the team meets for a daily scrum meeting where they discuss what they are working on and if they are blocked or stuck on anything.
- At the end of a sprint, there is a retrospective to see what went well and what needs to change.
- Then the cycle begins again with new user stories added, existing user stories selected for development and so on.
What is the Product Backlog?
The product backlog is the list of potential user stories that can be worked on. The list can contain tasks bugs and features as well.
It can be organized by priority, by estimated dollar value, by urgency, by number of customers who would be happy, or by some other criteria.
What is a User Story?
In contrast to traditional project management where work packages are worked on, in agile you have a user story.
Each user story includes the user persona or actor. It also includes what they would like to be able to do in the system.
Examples of user stories
- As an author, I would like to write a book (for a word processor)
- As the system administrator, I would like to view all performance metrics of our active systems
- As an educator, I want to create a course outline
- As an teacher, when creating a course outline, I want to include PDF presentation files and images
Estimating Time/Effort to Implement a User Story
For each user story, it is important to understand the effort involved in implementing it. The team members who will be working on the user story should take some time to break it down into sub-tasks and estimate how much time/effort they will take. If a user story looks as if it will take more than one sprint to complete, it’s important to know this sooner and estimation is how we determine that.
Story points, t-shirt sizes or days or weeks?
Some SCRUM implementations use “story points” to estimate the effort, others use t-shirt sizing such as small, medium or large effort. Others will use the number of days it will take and include a buffer of days to account for unknowns such as QA or testing or debugging time.
In project management outside of SCRUM, the estimation will usually be in number of days as part of a Gantt chart. Story points and t-shirt sizing are less precise and this is on purpose. It helps the team understand that it is a rough estimate, an approximation of effort that could change as the tasks are implemented and the work progresses.
Estimate and re-estimate
For example: it is possible to initially estimate a user story as being 3 in terms of story points. After some investigation and some work, the user story is re-estimated as a 7 in terms of effort. At that point, it may be prudent to move the user story into the next sprint or to re-evaluate what other tasks are being worked on and shift resources.
What is a Sprint?
A sprint is a block of time during which user stories and tasks are worked on and (hopefully) completed. The user stories are selected from the product backlog and put into the sprint.
How long is a Sprint?
Sprints are typically 2 weeks long. Most companies and startups have settled on 2-week sprints and plan accordingly. However, various SCRUM books suggest that sprints can be between 2 and 6 weeks. The longer the sprint, the more planning goes into it.
It can take up to a few hours to plan a 2 week sprint, anything longer than that and you may want to adjust the length of the sprint or select fewer user stories to work on within the sprint.
Varieties of SCRUM Meetings
There are two major SCRUM meetings:
- Sprint planning meeting
- Daily stand up meeting
These are the SCRUM meetings that every company that says they are agile uses to plan, execute and monitor the work.
There are other meetings too, such as the SCRUM Retrospective. This meeting is, unfortunately, not seen very often. Sometimes it is called a post-mortem, and sometimes they are conducted only after disaster strikes. Sprint retrospectives can be seen as “closing a project phase” in project management.
If you have Sprint Retrospectives, ensure that the notes taken during that meeting result in something actionable. Too often, it’s seen as a way to close the sprint rather than as a way to improve the team and the work.
SCRUM Tools
The typical tools used for SCRUM Agile planning are: