Scrum Sizing Guide
Version 22_2
Introduction
This document describes how to use the Scrum Sizing sheet. It explains the estimation values
and the options you have available to you to complete your sizing.
A scrum sizing sheet is typically the next step in sizing a project after having first filled in a
Case Type Backlog. A Case Type Backlog provides an initial range of effort and duration. It
allows you to set certain project attributes, such as the number of scrum teams, to arrive at a
mid-level estimate. The scrum sizing sheet enables you to go to a lower level of detail,
provides more options such as making adjustments to estimates based on assumptions, and
provides more flexibility when determining the size and makeup of the project team.
This document does not provide guidance as to how to estimate effort, nor does it provide
strategic application specific guidance.
Getting Started
The Scrum Sizing sheet is available from Pega Community. There are two ways in which to
generate a sizing sheet:
• Create manually using an empty sizing sheet
• Create a sizing by importing case features, interfaces, reports, etc from a Case Type
Backlog
If you create the sizing sheet by importing from a Case Type Backlog, all case types, features,
reports, etc are auto-populated into the sizing sheet. You can then make adjustments, add
additional user stories, Prepare tasks and additional services such as a design review.
Navigating around the Scrum Sizing Sheet
All tabs provide inputs into the Scrum Summary tab which displays an overview of the
project schedule, resource allocation, and proposed staffing plan.
The green tabs list out the task deliverables and consulting services. The beige tabs enable
you to arrange the staffing for each of the three phases of Prepare, Build sprints and the
Hardening sprint (Sprint Z).
Sizing Explained
Each of the green tabs contains effort that will be delivered as part of the project. This can
range from interfaces to consulting services such as performance tuning. These tabs contain
the pure delivery effort, divided into design (elaboration), build and test effort.
If you add up the effort to deliver each work item in the green tabs i.e. the prepare activities,
case features, interfaces, reports, correspondence, and CDH / Marketing specifications, this
Scrum Sizing Guide
Scrum Sizing Guide
Version 22_2
will give you the total delivery effort BEFORE you add a resource profile. As a general rule,
once you apply a resource profile to deliver the backlog, the total number of hours effort to
deliver the project will increase by a factor of 2 to 2 ½ times the pure delivery effort.
For example, if the work item delivery effort is 1250 hours, sometimes referred to as the
‘bottom-up’ estimate, once you have determined the correct resources to deliver the project,
the delivery effort will increase to 2500 hours (the ‘top-down’ effort).
This screenshot highlights the full implementation effort estimate once a resource profile has
been added:
The Case Type Backlog is consistent with this estimation rule.
So why is the full project effort double the pure delivery effort? There are several reasons,
including:
1. Realistically, it’s not as simple as a resource working 8 hours solidly each day.
Productivity for each resource is more likely to be 6 hours per day, accounting for
Scrum ceremonies, meetings, waiting for approvals, performing deployments etc.
2. Not all resources will contribute 100% of their effort to the backlog. This includes
Project Delivery Leads, Experience Designers and resources that dedicate some of
their time to enablement
Scrum Sizing Guide
Scrum Sizing Guide
Version 22_2
3. Client resources are added to the implementation effort e.g. Product Owner, Test
Lead, Business Analysts that will not burn down the backlog at 100% productivity
This document explains how to manage the resource profile. But first, we need to understand
how the bottom-up delivery effort is calculated.
How the Case Feature estimates are calculated
The CaseFeature Details tab contains the breakdown of the functional tasks required as part
of the implementation. Each feature has a separate line item in the sizing sheet e.g.
‘Advanced Search’ will be recorded as a single line item.
The effort is calculated automatically once you set the Item Maturity, Item Type and
Complexity either in Pega or manually. Also, by specifying an additional Channel (by putting
an ‘X’ in the channel box) this will increase the auto estimated hours. You can then adjust the
automatic calculation using the Total Adj Hrs column (negative or positive adjustment). All
adjustments should have a justification comment:
The Auto Estimate Hrs is a sum of ‘Design’, ‘Build & Test’ and ‘Test’ columns, with a multiplier
applied depending on the channels.
The table below explains what these columns mean and what % of the total effort they
constitute. The % of estimate is based on a Medium complexity before channel multipliers
are applied:
Activity Description New User Story % of
estimate
Design An estimate for the elaboration which includes 30%
preparing for and executing a DCO session, as well
as writing-up of a case feature, interface or report.
Design also includes LSA / SSA design effort and a
review of the user story by testers who will prepare
test scripts (as part of the test effort).
Scrum Sizing Guide
Scrum Sizing Guide
Version 22_2
Build & Unit Test This is the System Architect effort to configure a user 40%
story, report, interface. It includes creating and
executing unit tests (using PegaUnit) as well as defect
fixing.
Test This is the effort required to write test scripts, 30%
prepare data and test a user story, interface, report,
etc once the configuration and unit test is complete.
This effort includes testing the user story during the
sprint and any end to end testing required during a
hardening sprint (sprint-Z, which is the last sprint in a
release)
This effort does NOT include specific
penetration/security testing, nor does it include
performance testing & support.
Total Effort (before an adjustment) 100%
So why is it important to understand the above table? It’s because it helps determine the
resource Allocation to Dev Activities on the Sprint 1-Sprint N tab (more on that below).
How to set up the Resource Profile
The Scrum Sizing sheet comes with a default set of resources. You can remove and add
resources depending on the shape and size of the proposed project. This guide describes
how to manage the Sprint 1-Sprint N resource profile. An example profile is below:
Scrum Settings
The Sprint Hours/Day and Sprint Backlog Planning % both impact the Dev Effort Capacity
for a Sprint i.e. the higher the Sprint Backlog Planning %, the lower the capacity because
Scrum Sizing Guide
Scrum Sizing Guide
Version 22_2
more time is spent in sprint ceremonies. The higher the Sprint Hours/Day, the higher the
capacity because more time is spent reducing the backlog.
Make sure that you consider both these levers together when you set them. As a general rule,
if Sprint planning, daily-stand-ups, sprint reviews and retrospectives constitute 12 hours per
sprint in a 10-day sprint then this equates to 12 hours / 80 hours = 15%. Allowing for Sprint
ceremonies outside of Sprint Planning plus additional meetings this may equate to 6 hours
per resource allocated to the sprint per day.
Productivity
This column is used mainly in a co-production environment, typically where newly enabled
client resources may be allocated full time to the project, but allowances are made for them
learning on-the-job.
Certified Pega resources should be 100% productive except for junior resources, whereas you
can apply discretion to the productivity of client resources. Productivity may increase from
sprint to sprint in which case, you should pro-rata this across Sprint 1-Sprint N. Refer to the
notes on the Scrum Sizing sheet for further guidance.
Resources classified as ‘Other (Non-Dev)’ have effective productivity of 0% which means that
they do not contribute to the backlog burndown.
Scrum Sizing Guide
Scrum Sizing Guide
Version 22_2
Days Available During Sprint
When specifying the number of days available during the sprint, if you double the number of
days for one resource, this is the same as adding an additional resource. For example, if a
test resource is allocated 10 days to a 10-day sprint and you set the Days Available During
Sprint to 20, this will increment the test resources by one on the Scrum Summary tab e.g.
Allocation to Work Activities
As standard, resources will contribute 100% of their productive time to burn down the
backlog; either design, build & unit test or test effort.
To the right of ‘Allocation to Work Activities’, you will see the hours allocated to each activity.
Scrum Sizing Guide
Scrum Sizing Guide
Version 22_2
The hours allocated to work activities are calculated by a combination of role, sprint
hours/day and sprint backlog planning %. If a resource has 80 billable hours available to the
sprint, this will be spread across design, build & test, test and sprint ceremonies,
management, mentoring effort.
Different roles will burn down different types of work e.g. the testers will burn down a small
element of design but a lot of the test effort. This is automatically calculated and cannot be
overridden.
The table below illustrates the percentage of work hours that are allocated to specific
activities based on role before time is allocated to sprint ceremonies and/or mentoring.
Role Allocation to Work Activities Comments
Lead System Architect 50% Design The LSA will typically focus on designs, working
closely with the SBA, and support & review during
50% Build & Unit Test
build & unit test.
(Senior) System Architect 10% Design The System Architect will predominantly burndown
build and unit test effort which includes and defect
90% Build & Unit Test
fixing effort.
System Architects also contribute to design effort so a
provision has been made for this.
Not that a UI developer is classified as an SSA.
Senior Business Architect 80% Design The SBA will burn down the design (elaboration)
component of each line item.
20% Test
During in-sprint testing and testing during the
hardening sprint, the SBA will be involved in helping
to resolve defects and clarifications, so an allowance
is made for this.
Test Lead / Tester 10% Design Test team members will prepare for testing, execute
tests in sprint and during Sprint-Z (hardening, the last
90% Test
sprint). Provision is also made for design discussions
as part of a 3-way handshake and any test
preparation that may be required during design.
For co-production, if an experienced System Architect is mentoring a new System Architect,
then the experienced architect should have their allocation to work activities reduced by 20%
for every System Architect they are mentoring. The hours are allocated to the ‘Sprint
Ceremonies’ column. In addition, the new System Architect should have a lower productivity
while they learn so that the sizing and timelines take this in to account i.e. if you assume a
Scrum Sizing Guide
Scrum Sizing Guide
Version 22_2
team of three new System Architects will burn down the backlog as quickly as experienced
System Architects, your plan will likely be delayed. This is an example of how a co-production
profile should look where one new SA is being mentored by an experienced SA:
In the above example, the Pega SSA dedicated 16 hours per sprint to mentoring and the new
SA is learning for 48 hours. These hours will vary depending on the % allocated to sprint
ceremonies.
Effort Details
This section, which appears on each of the beige tabs, summarises the total effort that
appears on corresponding tabs e.g. on the Sprint-Z Hardening tab, the hours totaled below
are based on the total effort recorded on the green Sprint Z-Hardening Details tab.
Scrum Sizing Guide
Scrum Sizing Guide
Version 22_2
You can add a contingency to each task. As you can see in the above example, the effort
exceeds the capacity, so the Dev Effort Capacity total is highlighted in red and so is the total
for the Effort Details. This requires additional resources to be added to the hardening sprint.
Proposed Staffing Plan on the Scrum Summary tab
Once you have updated the beige tabs with appropriate resourcing and updated the
consulting Services tab, you can view the Proposed Staffing Plan on the Scrum Summary tab:
SPRINT 1- N TOTAL
SPRINT-INITIATE SPRINT-Z
Sprint-1 Sprint-2 Sprint-3 Sprint-4 Sprint-5 (HRS)
SOURCE ROLE
02-Jan 09-Jan # 16-Jan 23-Jan 30-Jan 06-Feb 13-Feb 20-Feb 27-Feb 06-Mar 13-Mar 20-Mar 27-Mar 2-Apr
# #
w1 w2 w3 w4 w5 w6 w7 w8 w9 w10 w11 w12 w13 13 Wks
Pega Practice Leader 0.1 4 4 0.1 4 4 4 4 4 4 4 4 4 0.1 4 4 52
Pega Engagement Leader 1 40 40 1 40 40 40 40 40 40 40 40 40 1 40 40 520
Pega (L/S) Business Architect 1 40 40 1 40 40 40 40 40 40 40 40 40 1 40 40 520
Pega Lead System Architect 1 40 40 1 40 40 40 40 40 40 40 40 40 1 40 40 520
Pega (Sr) System Architect 2 80 80 2 80 80 80 80 80 80 80 80 80 1 40 40 960
Pega Experience Designer 1 40 40 0.5 20 20 20 20 20 20 20 20 20 1 40 40 340
Client Product Owner 1 40 40 1 40 40 40 40 40 40 40 40 40 1 40 40 520
Client Test Lead 1 40 40 1 40 40 40 40 40 40 40 40 40 1 40 40 520
Client Tester 0 0 0 2 80 80 80 80 80 80 80 80 80 0 0 0 720
Client Business Architect 1 40 40 1 40 40 40 40 40 40 40 40 40 1 40 40 520
Client System Architect 1 40 40 2 80 80 80 80 80 80 80 80 80 1 40 40 880
Weekly Subtotal 404 404 504 504 504 504 504 504 504 504 504 364 364
10.1 12.6 9.1 6,072
Sprint Total 808 4,536 728
Getting the staffing right is an iterative process that will involve making changes to the
resources on the beige tabs then reviewing the impact of those changes on the Staffing Plan.
In the screenshot above you will notice that Sprint 5 is only one week long whereas the other
sprints are 2 weeks long. In this example, you could make amendments to the Sprint 1-Sprint
Scrum Sizing Guide
Scrum Sizing Guide
Version 22_2
N beige tab to reduce the number of Sprints to 4 e.g. add a resource or make some staffing
assumptions that will increase capacity (i.e. productivity or allocation to work activities).
Multi-Release Schedule
If you are planning multiple major releases you can use the Multi-Release Schedule flag on
the Scrum Summary tab:
We recommend using this only for large projects that involve a more traditional approach of
large releases. Pega’s strongly recommended approach is to release MLP within 90 days or
less, then to release every one or two sprints after the MLP release so that the client can
continue to receive continuous improvement and value rapidly. The Multi-Release Schedule is
not suitable in that scenario and instead release effort should be built into every sprint e.g. as
part of the CI/CD pipeline.
If you are using this setting, ensure that you set the release tags on each line item on the
green tabs e.g.
This will result in a profile that will look something like this:
Scrum Sizing Guide
Scrum Sizing Guide
Version 22_2
When using this setting, a useful table appears on the Sprint 1-Sprint N beige tab:
This setting can be toggled on and off.
Sprint-Prepare Task Details
This tab lists out pre-defined tasks that are typically performed during the Prepare phase.
You can add, delete or edit items in this list.
By setting the ‘In scope for this project?’ flag to ‘No’ it will remove the hours to complete the
task from the sizing. The line item can remain in the sheet in case you decide to add it back in
later, or so that it is clear you have consciously removed it from scope.
The ‘Estimated Hours’ to complete the task can be amended. These hours are placeholders
and should be reviewed for accuracy when completing sizing.
You can set a release tag for Prepare but the default is to assume that there is no release tag;
Prepare should happen once per project but there may be exceptions to this.
Sprint-Z Hardening Details
Specific tasks are added to this tab for the final sprint during each release. Typically
hardening includes the following tasks, among others:
Scrum Sizing Guide
Scrum Sizing Guide
Version 22_2
Consulting Services
Use the Consulting Services tab to include additional services such as performance tuning
and health checks. Hours you add here will automatically update the Scrum Summary for the
specified role.
Other Considerations
Some other key points:
1) A UI developer should be classified as an SSA in the sizing sheet; there is no separate
classification for a UI developer (who are specialist SSA’s).
Scrum Sizing Guide
