welcome to the user guide

about the user guide

As you can see, EstimZen is not complicated, so neither is our user Guide. It is aimed to help the developers estimate their projects and not to train the new estimators. If you have questions about certain topics or you think we should explain some sections in more details, don’t hesitate to contact us.

what is EstimZen ?

EstimZen is a cloud software as a service tool that can help you make a simple, quick and reliable estimates of your agile projects with standard story points (SSP). It is based on the agile principles but, instead of talking about estimating agile projects, we prefer to use the term agile estimating.

1. Simple, quick and reliable

Estimating doesn’t have to be so complicated. With EstimZen, there is no need for set-up efforts, calculating and training in estimating. Start estimating your project right now and obtain a reliable estimate in a couple of minutes!

To calculate the software’s size, EstimZen uses COSMIC, the method for software functional size measuring that is internationally recognized and ISO standardized. The team productivity factors are based on COCOMO II, the reference in software cost management. But, to make them work, we simplified these concepts and built a simple estimating process that is adapted to the everyday needs of agile teams.

2. Flexible

Estimating can be performed in different phases of a project’s life cycle: up-front/early estimate for budget purposes and detailed estimate for Release/Sprint planning. Furthermore, we believe that the best person to estimate the software is the one who should develop it. So, the effort estimates provided by the tool can be modified based on your own comprehension of software uncertainty.

3. Aligned with agile development methods

Your agile team discuses and defines functionalities (complexity) of software items and the tool calculates the project’s size, efforts and duration. The estimating process is adapted to the agile philosophy and methodology, and should not slow down or impact the dynamics of your team. As John Maynard Keynes said: “It is better to be roughly right, than precisely wrong”.

how EstimZen works ?

Create an account and choose a subscription plan

By registering, you are automatically assigned to a free plan and redirected to Projects page where you can start creating your projects. Free plan allows you to use all available features in order to create an estimate for your project. If you want to estimate more than one project at the same time and keep track of estimating data, you have to subscribe to the Unlimited plan.

To do so, go to your account settings by clicking on your name or email address on the bottom left of the page, choose Account in the menu and then go to the Billing section. After that, you have to enter your credit card information and choose Pro plan. You are allowed to downgrade to free plan anytime but since free plan allows a single project, you will lose access to all of your projects data except the first one. You can also switch from Free plan to Unlimited plan at any time without having to re-enter your credit card information.

Our billing process is managed by Stripe, the leading online credit card processing solution. You don’t have to worry about the security of your credit card information. We don’t store your credit card data on our servers, all is securely managed by Stripe.

EstimZen pricing

• Pro plan is 295 $ CAD per month.
• Billing is monthly and automatic on your credit card.
• A new invoice will be generated each month and the payment receipt will be sent to your email address.
• You can switch from one subscription plan to another at any time, your invoice will simply reflect it when the time comes.

Estimate your project in 3 simple steps

Step 1: Create a project

Click on the button "New Project" to create a new project/release. Clicking on your newly created project will bring you to the project details page where you can enter the basic information about your project. It is very important to set up work hours per week (official work hours per week, ex. 35, 37.5, 40) because this information will be used to compute your sprint capacity and velocity. It is also important to choose the planned duration of project iteration/sprint in order to calculate the project release duration.

Step 2: Set-up your project team (roles and productivity)

Team roles

In order to estimate team capacity and project duration, you should enter the resources assigned to your project/release. If you are in the early project planning phase and don’t know your future team, you can make the estimate without entering the team members (you can do it after). It is important to mention that the listed resources can be divided into several teams.

In the beginning, set-up the team for a release (all resources regardless how many teams you are planning to deploy) and the tool will provide the project duration. If you don’t know your team, you can estimate the size and the effort for release (sum of items) and make the simulations with different sizes of the team to find the optimal duration. For example, you estimate the items (epics and stories) for a release and, as a result, you have 1000 pts and 60 person months. It is a very valuable information for an initial planning in a way that you can say: I’ll have one team of 6 resources so I should finish my release in 10 months. Or, if you have the resource capacity and if the deadline is an issue, you can put two teams of 6 persons each and finish your release in 5 months.

If you have more than one team for one release and each team has its own backlog, you should consider each team and its product backlog as a separate project/release. Also, the hourly rate of each resource profile is used to calculate the average team cost that is after used in sprint capacity calculation.

Team productivity

The productivity factors impact your team productivity. They should be set-up before the start of the project. However, if you don’t know your team members, you can set-up your productivity factors anytime in the project lifecycle. The productivity factors should be an average value based on the experience of team members, but they should be written in a tool for a team and not for each member of the team. Every change of productivity factors will affect the estimate of efforts and costs as well as the estimated velocity.

Step 3: Add and estimate project items

EstimZen makes it trivial to estimate items. For each or your project's backlog items, you can perform either a general estimate (used for early estimate) or a detailed estimate (used for release and sprint estimate). See the estimate criteria description section for more information on the detailed estimation criterias.

Start by adding items to your project. Items can be at different level of details (e.g Feature, Epic, User Story) and this depends on the current phase of your project. If you are in early planning phase, you backlog will probably be composed of big items (epics). When you start your project, you have to decompose your items, so your backlog will mostly contain User Stories and some epics which are not yet decomposed.

First, enter the name and the description of the item to estimate. Next, choose the item’s type: Web (business logic and user interface are estimated together) Client-server or, if you apply component based development methodology, you can estimate separately the GUI and Business Logic. Finally, you can choose the complexity of the item. By choosing item's module type and complexity, EstimZen will automatically estimate the item and compile an estimate for the whole project based on standard criterion. If you think the estimate is not right, you can click on the item and dive into a more detailed estimate.

Detailed estimate with custom criterion settings

The estimating criteria concern functional user requirements (FUR) as well as non-functional user requirements (NFR). Every time you change the criteria or item’s general complexity, the tool will automatically update the estimate.

Estimate results

The estimate provides the size expressed in Standardized Story points-SSP, the effort expressed in person/hours and the cost in monetary value. The estimate of effort is based on the average industrial productivity or, if you know it (usually after several estimated projects), on your own productivity. This estimate is adjusted by the productivity factors you have entered for your team. However, as we believe that the best estimate is provided by the person developing the items, you can change the calculated estimate of effort and enter your own estimate based on your understanding of item’s complexity and uncertainty. To do so, for each item, you can choose the percentage you want to apply in order to increase or to reduce the item’s estimated effort (use the slider on the bottom of every item). Warning: If you retake this item and want to adjust the estimate (change the complexity or some criteria), the tool will override your previous estimation and ignore your uncertainty factor.

Every time you make a change in your project details or on any project item, estimation is automatically computed and displayed in the Project Summary card. Click on ... to see more details.

estimate criteria description

Inputs

Enter the number of inputs (input screen, interface, tab, etc.) that modify one or more logical files by one of the following actions: Create/Add, Modify/Update and Delete. This input can be an internal input screen, an interactive input, an input from an external application or a hardware input. The components Web, C/S or Web-LA, must have at least one Input and either one or more Outputs or one or more Update.

Outputs

Enter the number of outputs in different forms (Screen Reports, Printed Reports, Forms, Documents, Notifications, Media Outputs, etc.) produced by the application for end users. You must also consider the interim reports (data group in the different layers of software) that are not visible to the end user.

Interface functional links

Enter the number of user interface elements that have functional links with other elements of the system (text box, list box, combo box, radio button, check box, button, etc.). Calculate each item in the list box as an element. Do not consider the elements that must be created in the interface, but which make no changes to the logical files (these elements are considered in the criterion: Interface Design).

Read/Consult

Enter the number of entities consulted (data bases, directories, data groups, etc.) and read by the item. Consider only read entities within the same application. If the read entity is outside of the application, use the criterion: Link to Other Entities.

Write/Update

Enter the number of entities (data bases, directories, data groups, etc.) updated by the item whether it is by creating/adding, updating/modifying or deleting data. Consider only the updated entities that are within the same application. If the updated entity is outside of the application, then use the criterion: Link to Other Entities.

Link to other entities

Enter the number of direct links (inputs and outputs) that the item has with external entities or systems. Consider the functional links only, i.e. the links based on data movement or data change.

Data management

Consider the complexity parameters related to operations and data manipulations that are not of a functional nature, such as:

• Data Entry Validations (either to allow only certified data or to prevent the acceptance of uncertified data)
• Complex mathematical and logical operations (a complex mathematical operation is one that uses one or more algorithms);
• Data Formatting (structure, format or other data elements that are not perceived as functionalities by users);
• Delivering Added Value by Data Configuration (adding, changing or deleting the reference data without changing software code or database structure).

In evaluation of the complexity parameters, consider the number of unique attributes that are added, changed or deleted and a number of Records configured.

Technical environment and architecture

The Technical Environment and Architecture aspects have to ensure the required level of application performance (speed and reliability of treatment, response time, etc.) and to enhance the application. The elements to be considered in assessing the complexity of this aspects are:

• Multiple Platforms: Ability to work on more than one platform (computing, software, hardware). Consider the nature and the number of platforms to operate (OS, languages, browsers, etc.);
• Database Technology – The complexity parameters to consider are Logical File Complexity and Number of database-related changes that are not functional and that should increase or maintain performance and data integrity;
• Multiple Input / Output Interface: The complexity criteria to consider are the number of affected data elements and the number of additional input/output interface in order to meet the large number of users and increased volume of data for a given period of time.

Interface design

This criterion relates to the design (configuration) of the interface that allows the end user to interact with the system. We must consider only the interface elements that don’t change the functionality of the system, but affect other non-functional elements, such as ease of learning, accessibility, usability, attractiveness, etc.

In assessing the complexity parameters related to the configuration of the interface, take into account the number of UI elements impacted (ex. text field, button, table, etc.) and the number of properties (ex. color, format, location, locked item, etc.) added or changed for each of impacted element.

The other aspect of this criterion is related to the Help function provided to users. In the assessment of the complexity, consider the help type (User Manual, On-line text, context, etc.) and the number of affected help item.

Multiple inputs/outputs methods

This criterion concerns the ability to accept multiple input and output methods without affecting the functionality of the application. These methods include different techniques or media type, such as PDF, voice message, screens, Office document, SMS, Smart mobile devices, Bar Code reader, etc. Take into account only the inputs and outputs that are not counted as functional links. In the assessment of the complexity, we must consider the number of inputs/outputs and the number of impacted data elements.

glossary terms

• Backlog

  The list of items that are planned to be estimated and developed in a current release.

• Backlog item

  The functional component or unit of work listed in item’s backlog. Can be of different level of detail (feature, epic, user story, and task). Remark: As daily planning (tasks) is outside the scope of this tool, the tasks are not supposed to be part of this backlog item’s list.

• Epic

  A big US which usually cannot be developed in one Sprint and needs to be decomposed in two or more User Stories.

• User Story

  A requirement, feature or functionality that can be estimated and tested. User Story is a need expressed by customer in its own language. They are placeholders that start a requirements conversation between team members.

• Standardized Story Point (SSP)

  The SSP is based on functional (system’s functionalities/features) and non-functional requirements (often expressed as the acceptance criteria). SSP doesn’t depend on technology, developer’s productivity, environment, etc. With Standardized Story Points we estimate the size and not the effort.

• Effort

  Estimated work hours needed to develop the backlog item. The estimate of each individual item is based on direct cost of development, i.e. analysis, coding, test and deployment and doesn’t encompass the cost on project level (requirements, architecture, acceptance test, integration, etc.). The effort on project level is added to calculate the total effort/cost of the project (see total project effort).

• Sprint Capacity

  Amount of efforts your team can put in one sprint. Depends on your team capacity and sprint duration.

• Velocity

  The number of units of work (expressed in Standardized Story Points-SSP) your team can deliver in one Sprint.

• Number of sprints

  The number of sprints needed to accomplish your items backlog. Number of sprints multiplied with sprint duration gives the estimated project duration.

• Summary Cost

  The sum of the development cost of all estimated items. Based on summary efforts and average rate of project resources.

• Total project effort

  The sum of development effort of all estimated items + effort on project level. Total project effort is used in early project estimation in order to estimate the needed project resources.

• Project total cost

  The sum of development cost of all estimated items (direct cost) + the effort on project level (indirect cost). Project total cost is used in early project estimation in order to determine the project budget.

FAQ