Estimating Features for A Software Game
Ron Jeffries posed a software estimation challenge to determine the likely effort required to deliver a forthcoming featureset of a game that he and his team are writing. I decided to take up this challenge and carry out a COSMIC sizing estimate, and perhaps in doing so, will turn some heads towards the merits of CFP estimation and how it can help with design-thinking.
We are asked to estimate the effort required to design some functionality within a partially built game, here is the high level requirement:
Provide the ability for a Level Design Team Member to control the placing of Dungeon Objects, including monsters, player starting point, Loot-containing Decor items and the Loot they contain, and free-standing Loot items.
There is more context which can be read here:
https://ronjeffries.com/articles/-z022/0222ff/cfp-est-chal/
This is a high level requirement. There is quite a lot that we don’t know. A precise CFP measurement of the final delivered software is not possible, but we can measure the requirements provided that they are clear enough for consistent interpretation.
The two main reasons for seeking estimate in order to have a reliable indication of the amount of effort needed (which usually tells us the cost) and the likely elapsed duration. Armed with these two pieces of information, we can plan effectively.
A functional size estimate can helps us answer these two questions, but also the process of estimation is valuable. The process of estimation helps us to clarify and improve the quality of the requirements which in turn can help to reduce rework.
First, we must establish what it is that we are estimating (and what are we not estimating). We can consider this as establishing the boundaries of the estimate. We will be estimating the size (not the effort) of the functionality to be developed for this featureset only. We are only considering the functionality as described, we wont guess any other functionality.
Given the high granularity of the requirements provided, we can only size what we know, and then allow for what we don’t know (ScopeMaster does both). So now let us dive into the details.
What the Software Needs to Do
“Provide the ability for a Level Design Team Member to control the placing of Dungeon Objects, including monsters, player starting point, Loot-containing Decor items and the Loot they contain, and free-standing Loot items.”
The overall goal is about controlling the initial placement of objects in a constrained space.
Considerations that are contained within the explanation include the following:
- Predefined 2D boundaries of allowable locations (floors not walls)
- We do need to recognise wall adjacency
- We don’t need to worry about halls, only rooms.
- There are different types of Object that mostly have the same characteristics for our purposes: Treasure, Décor and Monsters.
- Décor that contains Treasure
- Player (for starting position)
For now we will not worry about limits of how many objects can be placed on a level, nor whether many objects can be placed in the same location.
So we now start to break this down into a set of user stories (or user-oriented functional user requirements FUR). Of course we used ScopeMaster to help us accelerate this, in total I spent just under 1 hour reading and understanding the requirements, creating the user stories, refining them. (I then spent a further 1.5 hours writing this up and posting these results). ScopeMaster sized the stories for us but also helped to improve our thinking of the requirements and design simultaneously.
Here are the steps I took:
First, work out what user identifiable objects we need to work with, these are
• Levels (that have rooms)
• Rooms (that have dimensions)
• Objects (that have a starting location)
• Containment (describing when on Décor contains a treasure).
Then describe the functionality from a user’s perspective and the result is just these three user stories.
-
As level_designer I can select the level I want to work on, and the rooms therein
-
As a level_designer I can select a room [within a level] and create a level_object [with room_location at which to place an object]
-
As a level_designer I can lookup level_object and then create a level_object_containment
These were not my initial versions of the requirent. Each one had a few revisions. ScopeMaster provided feedback which helped me improve the quality as well as determine the size of each requirement.
Autogenerated Use Case Model Diagram for a set of Requirements
For each requirement we get a functional interpretation, which determines the CFP estimate and the data movement breakdown:
Functional interpretation of a requirement showing the data movements and CFP Size
Another potentially useful perspective on the requirement in the form a of sequence diagram (also auto-generated).
Autogenerated sequence diagram for an individual functional requirement
Given that the functional intent is revealed, we can start thinking about how to test the software delivered by these requirements. ScopeMaster does a lot of that work for us:
Autogenerated test scenarios for an individual functional requirement
Improving the Quality of Thinking and Requirements
The above illustrations that are autogenerated directly from requirement text, help us to reach a clear understanding of the functional intent of what has been written. For highly experienced software development professionals, these illustrations may reveal little extra insight on a mere three requirements, but when working on a large set of requirements they can be very effective at exposing potential problems before the code is written. ScopeMaster can analyse a set of up to 2500 requirements.
Size Estimate
COSMIC sizing is an agile-friendly methodology for software functionality size measurement, because it allows you to size the requirements that you know without needing to know other requirements. I may have misread the challenge and ideally would have a few follow up questions, but given what I know from reading the challenge the size (of what we know) is 17 CFP.
Effort and Duration Estimates
What we’d really like to know is how much effort and how much time it would take to deliver the functionality. Studies, benchmarks and experiences have shown that typical averages for dev and unit test is around 4-8 hours per CFP. Considerably worse than this is occasionally observed (20+ hours /CFP) in inefficient organisations. At the other end of the spectrum, highly competent teams, with high levels of re-use can get this down to 2-3 hours/CFP but this is rare. We will for this sake of this exercise assume that highly skilled developers, with good tooling are working on this. Their only constraint is volatile requirements, so 4-6 hours per CFP is a reasonable range. I typically never offer point estimates, only ranges, with explanations. And so we have an estimate range of 68-102 hours of effort. A developer is rarely productive for more than 5 hours per day, so that would be 14-20 days.
But wait! There might be more (knowable unknowns). ScopeMaster has performed CRUD analysis on the set of 3 requirements and identified that there may be extra functionality that we missed:
If the developer is expected to build all of the missing CRUD functionality also, then the potential is for this work to balloon to 53 CFP (42 -63 days).
Conclusion
COSMIC sizing follows principles of software design, measuring data movements only within the given context. It is applicable to the vast majority of software domains including games. The sizing methodology helps with the design thinking, and as such we usually end up with better requirements and better design fit. Sizing can be done manually and it takes a very small percentage of the developer time to do so. It is even faster when using ScopeMaster®. In this case the work of reading, understanding, analysing, clarifying and sizing the requirements took just 1 hour. This represents just 1.4% of the total effort (or just 0.3% of allowing for sized missing requirements). Remember that what you need to know to size the requirements in CFP is a subset of what you need to know to build them – i.e. there is no waste.
When challenged by a manager/exec it is important to know the boundary of impossibility. CFP helps us understand the minimum time it is likely to take deliver this functionality. In this case, less than 68 hours would be good, less than 32 hours would be quite extraordinary.
The more we know about where we want to end up the fewer dead ends we will have to take along the way. In other words, having clear requirements will reduce rework. COSMIC sizing and ScopeMaster accelerate the work to get clarity on requirements, size and design, thus together they can reduce rework and bring greater certainty to effort and duration of software delivery.
I’d like to thank Ron Jeffries for the challenge, and I hope you find this helpful.
Addendum
Have written this up, I went back and noticed that I had omitted the functionality of “initial placement of the player”. This would at least 3 CFP.
