Why you should start estimating based on modules
June 21, 2016
Historically, when estimating a web application, one of the first questions is, inevitably- how many templates are there? This question is often used as the baseline for which the entire estimate is created. The higher the number of templates, the higher the estimate. This approach generally follows a linear curve. While it may sound intuitive at first, this approach becomes problematic when estimating a project on any platform, for this post, we’ll use Sitecore as an example. In the rest of this blog, let’s assume our goal (as it should be) is to write the most accurate estimate possible. In other words, the total amount of work performed is equal to the estimate given. In real-life this is nearly impossible, but nevertheless, a goal that should be reached for.
What is a template?
To a design agency, a template might be a single photoshop file that a designer worked on for a few hours, let’s call it Article. Next, let’s assume there are a few more photoshop files: Gallery, Contact Us, and Leadership Board. From the historical sense, we have 4 total templates.
While this may fit the dictionary-esque definition of a template, it only provides a small amount of assistance with regards to an accurate estimate. Sitecore applications are not constructed one page at a time- at least they shouldn’t be. Instead, a Sitecore page is built via a series of modules that come together when the URL is requested. The page is the final composition of all required modules.
What are modules?
Think of them as reusable pieces to a puzzle. Logical units of functionality that appear one or more times on a site. Examples of a module could be an image slider, a “tiny cart” summary, a news feed block etc. In Sitecore, these can become sub layouts, be used in webforms; built as user controls, or in angular; created as directives.
Consider the graphic below. Items 1, 2, 3, 4 and 8 are all global elements that need to be developed once and used on all other pages. Items 5 and 6 may be toggle-able depending on the type of page in question, again developed only once, but used multiple times.
Item 7 is the only feature that makes this particular page unique. Estimating the newsroom page is really just estimating the single control that makes this page unique.
The above image illustrates how modules may comprise an actual end user layout and below illustrates how modules might look in an admin or content entry area once they are implemented:
Is this really the best way to create an estimate?
Yes. Constructing estimates in the same manner that the project is to be built makes sense on several levels. Firstly, if you build your estimates with this approach, when it comes time to create tickets and assign work a major portion of this work is completed since each module was estimated separately. Secondly, no one wants to spend a lot of time on estimates. A seasoned developer is able to look at a design (PDF, PSD, etc.) and quickly deconstruct it into it’s component parts. Finally, breaking down a design into individual pieces makes it less likely that something will slip through the cracks. It forces a developer to think “How does this piece work?” without being bogged down by the entire page. Often we have found that this approach brings up important topics that haven’t been considered by the design agency. Functionality such as, “Where will the list of articles pull from? Is it dependent on the current page or is there a global repository?”, is brought to light before development begins.
Also, simply estimating on template count alone does not convey inherent complexities of the design itself: one template may have a “hero image”, another may have an image slider. The overall work effort of those two parts are not equal. Given that scenario, any templates that also have image sliders like the second template, will need considerably less work to include the slider. With component-centric estimation in mind, it not only gives a more realistic estimate, but it will also force the dev to deconstruct before implementation. Deconstructing will help illustrate shared functionality which helps speed up not only development (more granular development concerns and integration points) but design and styling effort as well (given the right classes on an element, front-end developers will only need to make one-off tweaks).
To note: Although we are discussing using component-centric estimation, the amount of different page types/templates will still factor in the end estimate in the sense that the more templates a module appears on, the more times it will need to be set up as such: 4 templates having an image slider, only the initial one will require the work effort of building, but the other three will still need it to be associated/dropped on the template, requiring some amount of effort.
Stay up to date with our email updates!