Thought Leadership

December 10, 2020

Release Planning - Part 2: Determining Scope, Resources & Time

In Part 2 we will go into the details for Defining the Scope or what we need to Build, Estimating Techniques, Risk Factors, Resources & Budget, Determining a Team’s Velocity, and Developing your Time Estimates

Executive Summary

This is Part 2 of our Release Planning blog posts series, click here to go to Part 1.

In Part 2 of Release Planning, we will go into the details for:

  • Defining the Scope or what we need to Build:
  • Estimating Techniques - especially in the very beginning when there are many unknowns
  • Risk Factors
  • Resources & Budget
  • Determining a Team’s Velocity
  • Developing your Time Estimates


Scope - What we need to build

While every Development Team would love to know all of the details of what needs to be created or built, before starting the Project; the reality is that in today’s fast changing Business environment this is unrealistic to expect. Developing software is not like building a Bridge or a Tall Office Building. It is a virtual construct that can be changed, reformed, added on to, and modified over time. Granted that some changes are more difficult than others, but Software can still be changed.

So, when Estimating at the beginning of any Project we have those Features that we “Know” of with some level of detail. And we have the “Unknowns” - those Features that will need to be fleshed out, changed or added to the Project, due to changes in the Business or things that the Business did not know or could not have thought of initially.

Known Features (Epic Stories)

At the beginning of a Project and when planning out the Release Schedule, you want to identify at a Feature or Module Level, and where possible as many of the Epics that can be defined.

Example:  

REQUEST FOR QUOTE MODULE

Epic Stories Include:

  • Filtered View of Request For Quotes
  • Request For Quote Form (Header, Detail Line Item, Footer)
  • Kanban Board for Displaying Request For Quote Status
  • Services for Validating & Saving Request For Quotes
  • Submit Request For Quote by eMail
  • Submit Request For Quote by API

Unknown Features - Scope Risk

Examples of Unknown Features:  for the REQUEST FOR QUOTE MODULE above

  • Our major Competitor just came out with a new release and they have the ability to send eMails to a Vendor that they sent a Request For Quote to from within Google Mail, lookup and link the email to the Request For Quote.  Similar to what can be done within Salesforce.  We need this too.
  • The VP of Product Management has decided that they need to have the ability to attach Files and Images to the Request For Quote at both the Footer and the Detail Line Item level.

Both of these were not known initially, but have changed the Scope of the Project. In order to take into account these probabilities, most Agile Project Managers will build into their Estimates for the Release / Project a Risk Buffer. The question is how much does this Risk Buffer need to be?

Factors to Consider:

  • Previous Experience of the Product Management Team / Executives:
  • Do they understand what is required to build Commercial Grade Software?
  • Or are they used to having Developers slap something together that looks like it works, but is full of Bugs?
  • Are they reasonable in their negotiations?
  • Are they willing to listen to the Team as to what is feasible and what is not?
  • Is this a New Product or an Enhancement to an Existing Product?

And what do you do, when your Buffer is exhausted?

How do we Measure the Scope

Unfortunately, there is no single magic formula that is going to Estimate the Scope of Work for a Project with 100% accuracy at the beginning of the Project. It just isn’t going to happen. At the same time, as Technology Professionals we need to come up with an Estimate for the Business Executives, so they have at least an idea of what can be included (Features) within the Release, when it might be done, and how many resources might be required.

T-Shirt Sizing in Software Points

There are two ways to run a T-Shirt Sizing effort to come up with either a Quick & Dirty Estimate for each Module as part of the Planned Release, or a more detailed T-Shirt Size for each Epic Story within the Module / Release. In both cases, the most common method is to use a Modified Fibonacci Scale, similar to how one “Points” an individual User Story:  

0, 1, 1, 2, 3, 5, 8, 13, 20, 40, 60, 100, 160, 260, 420, 680, 1100

T-Shirt Sizing Modules for the Release

This is the quick and dirty method for coming up with an Estimate for each Module that is part of the upcoming Software Release. The benefits is that it can give you a rough estimate for the Scope of Work. The downside is that it is a rough (not detailed) estimate, so your “Cone of Uncertainty” that we will discuss later is much larger, so you will need to increase your risk factor.

T-Shirt Size  /  Number of Epics Roughly  /  Software Points Rough Estimate

X-Small  /  3  /  100

Small  /  5  /  160

Medium  /  8  /  260

Large  /  13  /  420

X-Large  /  20  /  680

XX-Large  /  40  /  1,100

Example:

Module:

Request For Quote

Description:

  • Filtered View of Request For Quotes
  • Request For Quote Form (Header, Detail Line Item, Footer)
  • Kanban Board for Displaying Request For Quote Status
  • Services for Validating & Saving Request For Quotes
  • Submit Request For Quote by eMail
  • Submit Request For Quote by API

T-Shirt Size:

So, at least 6 Epics, some of which may be complex or have additional unknowns.

  • Medium
  • 260 Base Points
  • Plus a Risk Factor
  • This is a SWAG (1)
  • 20% - 50%
  1.  SWAG - is a Scientific Wild Ass Guess, based upon your prior experience in working with this Client, other projects, etc.

T-Shirt Sizing Epic Stories that are Part of a Module

Similar to sizing a Module as above, but now you are focusing on more of the details for Each Epic. In many ways, this is similar to a Function Point Analysis, discussed below, as you are estimating roughly how many User Stories are in each Epic Story. Of course, you have to do some analysis, as you can have an Epic that has a whole bunch of very easy 1 Point User Stories, while another Epic dealing with Integrations that has only a few Epic Stories, but they are very complex.

T-Shirt Size  /  Number of User Stories Roughly  /  Software Points Rough Estimate

X-Small  /  3  /  13

Small  /  5  /  20

Medium  /  8  /  40

Large  /  13  /  60

X-Large  /  20  /  100

XX-Large  /  40  /  1,100

Be very careful of having Epic Stories that become too Large. If you are getting over 20 User Stories, you should probably break that Epic Story into two or more Epics. It is always easier to estimate smaller components, than larger ones.


Function Point Analysis

First created in 1979 for IBM, the concept is to define a unit of measure for the Business Value for a given component of software, compare this with prior Projects of similar type, and use this to estimate to determine the costs or hours required to build this component.

Function Points include:

  • Outputs
  • Inquiries
  • Inputs
  • Internal Files
  • External Interfaces

Each Function Point is then assigned a value based on its complexity. There are even Software Estimating tools that will develop an estimate for you, based on results from thousands of other projects. The biggest drawback is that it tends to hide the complexities involved with the Business Logic Tier (algorithms and microservices), which can be significant in a very complex application, like an ERP system. To get around this, you have to expand the model, or count these service endpoints & logic, etc. as something else.

Ultimately, whether you chose to use Software Points (a.k.a. Story Points) or Function Points, they are measuring the same thing - the complexity of a component in order to define what it will take to build it. A Function Point is however typically translated into “Hours”.

Budget and Resources

Whether you are using Internal Staff, hiring Contract Staff, or hiring a Professional Services organization to handle most or all of an implementation, you have to come up with a Budget for the Project / Engagement. And then naturally measure your progress against that budget.

Set or Fixed Budget

If your Board of Directors, Executive Team or CFO have set a fixed Budget for this Project, then this makes it easier up front, because you know exactly how much you have to spend on the entire Project.

The challenge is then that you have to watch every dollar that is spent on the Project to ensure that you do not go over the total Project Budget. Ideally you want to come in slightly under budget, and the best way to do this is to Allocate a Risk Factor for unknown Expenses or Overruns that will come up during the course of the Project.

These Risks Factors include:

  • Scope Creep - adding new functionality to the overall Scope
  • Scope Changes - changing one feature for another
  • Unexpected Technical Challenges
  • Poor Vetting - causing a turnover in technology, staff, or a Partner
  • Quality Control issues - causing unexpected rework

Unknown Budget - “Or You Figure it Out”

This normally occurs when either:

  • No one has an Idea of what exactly the Budget should be, but once You Set it, then that’s your Budget
  • Or, you really are in a very flexible position, where the Project must be done with the agreed upon Scope and a set Time / Schedule.  Of course, even in these cases the CFO may say you can spend whatever is necessary… BUT there are limits, and every good CFO is going to give you small chunks of your Budget at a time to spend.

The biggest challenge with the first Use Case is once you come up with a number for the Project; that is going to be the only number that anyone remembers. You can “qualify” this all you want, but most CFO’s and Business Executives are only going to remember that you said this is how much it will cost.

The Tightrope Walk - Assuming Too Much or Too Little Risk

Every experienced Project Manager will tell you that there is always a balancing act between including too little Risk assumptions, causing the Project to have overruns in Costs. And assuming Too Much Risk, which can cause the Project getting axed before you even begin, as the Business Executives may be thinking that you are “Sandbagging” your estimates.

It is always best in these cases, if you can find out what range they are thinking that this Project will cost, and then see if it is possible or not.

Time

If the Time is Fixed, then most of your planning efforts will go into figuring out how many Resources you need, or the exact Scope of the Project. Either way, you need to determine the Team’s Velocity.

Team’s Velocity

The Team’s Velocity is a measure of how much “Software” that the team can produce within a given period of time based on a certain number of resources. For most Agile Teams, you will measure this in terms of how many Software Points or alternatively Function Points are completed and accepted during a given “Sprint” (typically a 2 weeks cycle).

So, we have a typical Scrum Team comprised of 10 Resources:

  • (1) Product Owner / Business Analyst
  • (1) Scrum Master / Agile Project Manager
  • (1) Technical Lead
  • (5) Software Developers
  • (2) Quality Assurance Engineers

Then we would expect that a good solid team can probably produce somewhere around 70 to 80 Software Points per every 2-Week Sprint. A high performing team will be higher than this, while a more junior team will produce less. Whatever, your Team’s 6 Sprint Moving Average is, there are two Critical Things you want to look for:

Consistency

There will be some natural variance in every Sprint that the Team completes, but the goal should be to try and make the Moving Average as flat as possible, with ideally no more than a 10% +/- Variance. This is Extremely Important, because it gives the Business confidence that the team can deliver at a consistent pace, and that when you provide even SWAG Estimates they are more likely to be believed.

What you want to avoid at all costs is a Roller Coaster looking Velocity Chart, where the Team is all over the map in terms of what they are able to Produce. This tells any Business Executive that you and the Team don’t have your processes down and any estimates provided can’t be relied upon.

Avoid Doing This…   Don’t be This Team:



Continuous Improvement Over Time

The other thing that you want to look for is slow improvement over time, as the Team gets more used to:

  • Code Base
  • Business Processes
  • Internal Improvements through Retrospectives (what is working / what isn’t)

Just keep in mind a few things:

  • With a brand new Team you are going to see a large increase in Productivity during the first 2 months or so.
  • After that it will level off, but what you want to see is small incremental improvements at that point.
  • Naturally, there are always Holidays and Vacations that have to be taken into consideration, as this will impact the Team.

Now Calculate our Time Estimate

Using the following Example from above:

  • Request For Quote Model - Scope is expected to be 6 Epic Stories
  • 260 Base Points
  • Risk Factor of 20% to 50%:
  • Unknowns, Scope changes, additional QA testing, etc.
  • Total Points 312 to 390
  • Resources = 10 Resources (from above)
  • Estimated Velocity = 75 Points per Sprint (2 Week Cycle)
  • Conservative Velocity = 60 Points per Sprint
Estimated Time of Delivery (Development)
  • Best Case Estimate = 312 / 75 = 4.16 Sprints
  • Rounding to the Next Whole Sprint = 5 Sprints
  • 10 Weeks of Development Effort
  • Worst Case Estimate = 390 / 60 = 6.50 Sprints
  • Rounding to the Next Whole Sprint = 7 Sprints
  • 14 Weeks of Development Effort

This is a CRITICAL POINT - thus far we have only estimated the Software Development efforts, including:

  • Requirements Definition
  • Software Architecture & Design
  • Software Development
  • Unit Testing
  • Code Reviews
  • Quality Assurance Testing
  • Defect / Bug Fixing
  • Minor Changes in Scope (Risk Factor)
  • Acceptance Testing Cycles

Additional “GO LIVE” Factors

However, in many Projects, you will have a lot of additional Factors to take into consideration, and these need to be added to the Project’s overall Time Estimate.  Because at the end of the day, what the Business Executives want to know is when can we start using the new software or when can I start Selling it.

These Additional “GO LIVE” Factors can include:

DevOps Deployment Schedule

Depending upon the size of the Organization and the Criticality of the Software being deployed / implemented, you may have a very formal Production Change Control process. In these cases, you may only be able to deploy new software or updates on a set scheduled basis. It is important to determine what this Schedule is and the process, and include this time in your estimates.

Training

If you are implementing an upgrade of an existing Application and there are few User Interface changes, then little or no training may be appropriate. However, if it is a brand new Application, then you should be prepared to have someone create either a Training Program or an on-line Tutorial for the Users to learn how to use the Application.

Also, don’t forget that in a very complex system, you may also need to train the System Administrators.

Documentation

What types of Documentation do you need to create and/or update:

  • Release Notes
  • System Administration Documentation
  • Standard Processes & Procedures
  • Standard Jobs & Job Schedules
  • How to Activate / Inactivate  new Users / Roles / Groups
  • How to recover the System
  • Etc.
  • End-User Documentation
  • On-Line Guides
  • On-Line Tutorials
  • On-Line Help Text
  • Etc.

BETA Testing - Internal

Normally when you are doing Acceptance Testing, you are having a group of Subject Matter Experts test individual components of an Application. But once the Application has a majority of the components as “Feature Complete”, you can have an Internal Team start testing the fully integrated Application. Depending upon the Application and its Criticality, you may go through multiple iterations of an Internal BETA Testing, either with the same set of Users or a different group.

BETA Testing - External

Depending upon your Application and Target Audience, once you have completed your Internal BETA Testing, you may decide to open this up to External Users and Clients to gather their input and feedback. One word of caution, an External BETA takes a lot of effort and time to coordinate and gather feedback from your Testing Users. You also have the challenge where people will sign up to participate, but then never test anything.

The other Risk is to your Brand Image. Be careful of going into an External BETA where features are still not “Fully Baked”. You want to be as close to a final version of your Product as possible, with only “Fit and Finish” items or weird edge case Bugs remaining. If you go into an External BETA too soon, they will have a very negative first impression of your Product.

Data Migration - Mapping & Testing

In many Software Implementations, you may either be:

  • Migrating from an older legacy system to a new Application, or 
  • From one version to a newer version of the same Application, but with changes to the underlying Database / Data Structures

In both cases, you will need to go through an exercise to map the data and information from the older application to the data structures in the New / Upgraded Application. This often includes a process where some pieces of information may need to be Transformed from one Data Type (text, timedate, integer, currency, etc.) to another Data Type; or even separated or combined with other data before being Loaded into the new Data Structures.

This process is known as Extract Transform and Load (ETL).

Once you have the Data Mapped and the ETL Process down, then you will want to test it multiple times, to ensure that it is correct.

Security & Penetration Testing

For an Internal focused Application, your Security testing will primarily focus on the following areas:

  • Role Access & Permissions
  • As User X, I can only View / Create / Edit / Delete information, which I should be able to.
  • And I can’t do something that I do not have Permissions to do.
  • Password Rules and Complexity
  • For Sensitive Data - Testing who can:
  • Download Data / Files
  • Take Screenshots or Print Screen
  • Copy and paste Data
  • Print Information or a Form
  • Standard Security in Place to prevent Internal Hacking
  • Https encryption enabled

For External focused Applications, especially for Multi-Tenant Applications, you will want to do all of the above, along with:

  • Multi-Tenant
  • Client A - can only see Client A’s Information at all times
  • Parent Client Users - can see appropriate Child Clients Information
  • And you can have more complex Use Cases, involving Partners, Alliances, Consortiums, Grandchildren Clients, Overlapping Regions, etc.
  • Advanced Security in Place
  • Application is “Verified”
  • Https encryption & certificate is in place
  • Firewall Rules
  • Penetration Testing
  • Testing for Denial of Service Attacks
  • White Hacker Testing - where you hire someone to try and break in
  • Etc.

Conclusion

In Part 2 of Release Planning, we have discussed:

  • Defining the Scope
  • Estimating Resources
  • Determining a Team’s Velocity
  • Developing your Time Estimates

In Part 3 of Release Planning, we will go into the details for:

  • Creating your Release Plan
  • The Cone of Uncertainty
  • Creating Your Phase / Milestone Plan

To read Part 1 of the Release Planning series Click Here.

We hope that you have enjoyed this article and found it valuable.

Thank you, David Annis.

Case Study from Arkusnexus
David Annis
David is a VP and Agile Coach within ArkusNexus, having served in multiple CIO, VP of Software Development roles previously. He is based in Tijuana, Mexico, and assists our Sales, Marketing, and Operations Teams on critical initiatives and projects.
dannis@arkusnexus.com
RSS feed
Subscribe to our feed
Back to More ContentMore From this Author