This is Part 2 of our Software 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:
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.
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:
Examples of Unknown Features: for the REQUEST FOR QUOTE MODULE above
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:
And what do you do, when your Buffer is exhausted?
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.
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:
T-Shirt Size:
So, at least 6 Epics, some of which may be complex or have additional unknowns.
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.
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:
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”.
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.
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:
This normally occurs when either:
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.
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.
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.
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:
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:
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:
The other thing that you want to look for is slow improvement over time, as the Team gets more used to:
Just keep in mind a few things:
Using the following Example from above:
This is a CRITICAL POINT - thus far we have only estimated the Software Development efforts, including:
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:
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.
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.
What types of Documentation do you need to create and/or update:
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.
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.
In many Software Implementations, you may either be:
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.
For an Internal focused Application, your Security testing will primarily focus on the following areas:
For External focused Applications, especially for Multi-Tenant Applications, you will want to do all of the above, along with:
In Part 2 of Release Planning, we have discussed:
In Part 3 of Release Planning, we will go into the details for:
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.
