In 15 years working in software engineering, I’ve seen the industry come a long way. We’ve created tools and frameworks for software development, one layer at a time, that have increased the speed at which applications can be created 10 fold. We have API’s for standardizing communication, Frameworks for quick implementations of abstracted functionality, and drag-and-drop editors that allow junior developers to contribute equally to senior developers.
However, in all these years Project Management teams and developers alike still struggle with one universally difficult task: Time estimation.
This article will take a deep dive into practices that you and your product teams can take to gradually improve the results of your time estimation over the next couple of cycles. The changes are simple yet elegant, and will often involve a change of process in your product development lifecycle; however, I promise you these changes (if followed correctly) will have a positive and lasting impact on the accuracy of your sprint planning and the quality of your software products.
But before we dive into how to improve the process, let’s ask ourselves a serious question so that we can focus on the problem that we need to solve.
Why is time estimation (‘scoping’) so difficult?
Why is scoping & time estimation on tasks so difficult? Well, let’s paint a picture of a scene that i’m sure you’ve seen many times in your career as a manager or technical leader. Here we go.
Your boss gives you a task…
You’ve been asked by your bosses to take the team through the requirements document for your product, which we’ll call Product Z, and provide the business with a high-level estimate and release plan for when each feature of the application can be delivered to QA, and when is the final release ‘cut-off’ date for a production ready application.
As part of the request, your boss sends you an email with a link to the product requirements. This typically includes a spreadsheet or google doc, often hundreds of pages long, with feature requirements written in the standard “User Story” format. You sigh deeply, pour a new cup of coffee, print out the papers and begin to dig in.
The User Stories are broken up by Category or feature set; and you find yourself constantly going back and forth in the document referencing User Story XY158: “A user can do this” to User Story ABC823: ” A user can do that”. Finally, after hours of grueling (and very boring) back and forth referencing the documents with a couple high-level rough designs, you feel you’re ready to present this information to the development team.
Time to present the requirements to the development team…
Since you run a larger team, you schedule an all hands to go over the overall concept and then break out the requirements documentation into subteams, so that each team can review their particular feature set and come back with questions. After a couple days of planning (which involves back-and-forth on requirements, consulting with the business, updating the documentation, and a continuous consumption of coffee) your team finally feels they have enough information to start scoping. Oh, the design mockups that were given have not been updated during this time – but that’s not important right? You have feature the requirements updated, and that should be enough.
Each of the developers goes through their assigned user stories and provides estimates. Your team elected to use Story Points instead of hours, so as the developers provide estimates and break out who will work on what each sprint for the next 4 – 8 weeks, the scrum masters present to you their plan. They think that their features will take 4 weeks to build; 2 weeks to test with bug fixes, and everyone is confident that within 8 weeks the application can go live.
8 weeks into the project…
The go-live date has been pushed back twice now, and you’re 8 weeks in at your estimation of about 50% complete. The business is furious – everything was laid out according to them, so why is this taking so long?
‘Well for one’, you note to yourself, ‘the business keeps saying the requirements have been set, yet on 90% of the User Stories we’ve required business clarification to questions the business CLEARLY had never considered before’. Although you voice this in a politically correct way; the business still comes back and says the requirements have been set from the beginning – and these questions should have been answered when the team was scoping.
Ok. Take a deep breath and exhale… release the frustration. Let’s stop the example, you’ve lived it and you get the point. Now, let’s talk about how to fix it.
First, Throw Out The Written Requirements.
In the above scenario, which you have lived through, you were required to read through hundreds of pages of documentation. Let me ask you a question – have you EVER remembered verbatim a hundred pages of anything? No, of course not – that’s impossible. So if it’s impossible why do we expect our teams to do it, and ourselves to do it? Using this tool of accountability is setting ourselves up for failure.
Instead, consider taking your 100 pages of documentation and combining it down to 10 pages. If those 10 pages conveyed all of the information that was contained in the 100 pages of word document, would that be helpful? Of course, but how is that possible you may ask…. well my friends, have you heard of the adage “A picture says a thousand words”?
What are Visual Requirements
Visual Requirements are the process of taking written requirements and converting them into a fully designed, fully flushed out clickable prototype. If this concept is difficult to grasp and you would like to see an example, take a look at the Visual Requirements for our website, openforge.io
You’ll see in the clickable prototype that we’ve not only designed out every page, but we have mapped every single click of a button so that anyone with the link (in this case, our development team) can click through the entire application before they build it, and before they scope it. We do this so that when we ask the developers to scope out a feature, they can actually visualize it and see what they are building live in front of them.
This helps them quickly
- Understand the overall purpose of the page
- Understand the features the page will contain
- See how they’ve gotten to the page, and where they can go from the page (dependencies)
- See what kind of layout they’ll need to architect
- Approximate (based upon other apps they’ve built) what this page would take to build
We are visual creatures – everything we do has a visual element to it (ada disclaimer, this is not true for *everyone*, but for the majority yes) – so by using full designs during scoping the dev team is able to apply the requirements to a visual representation, which will yield much more accurate results.
Leave a Reply