paint-brush
Automating Task Estimating Process In JIRAby@maddevs
201 reads

Automating Task Estimating Process In JIRA

by Mad DevsJuly 31st, 2020
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

Andrew CTO at Mad Devs explains how we encourage our developers to estimate tasks using simple & smart Jira configuration. At the sprint planning stage, our PMs ask developers to fracture and estimate their tasks. This enables us not to overload the sprint and stay committed to what we can deliver on time. At times a developer may drill into an unestimated task which may let the entire team down. This person may be unaware of the full scope of work that he or she needs to do.

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - Automating Task Estimating Process In JIRA
Mad Devs HackerNoon profile picture

Planning means more than just “staying organized”

IT project management is hard to imagine without planning. Planning orchestrates the work of different project departments (software development, marketing, sales, etc.). Having a plan enables business decision-makers to stay focused on where they go and see the vector of product development clearly. Planning cannot work without estimating the time of execution for each of your tasks. Developing a habit of splitting your tasks into subtasks while defining the estimated time of execution for all of them is not easy. This sin can be common not only with Junior developers but more experienced professionals can also avoid estimates.

In this article, I’ll explain how we encourage our developers to estimate tasks using simple & smart Jira configuration.

Where the problem originates from?

To quickly start a new project in JIRA, our PMs often use the default settings for workflow, fields, screens, etc. These settings are a good fit for a broad variety of projects, which is excellent! However, if you have a more specific task to complete, you’ll need to go deeper into configurations, like in our example. You will have to learn something new, too.

At the sprint planning stage, our PMs ask developers to fracture and estimate their tasks. This enables us not to overload the sprint and stay committed to what we can deliver on time. However, at times a developer may drill into an unestimated task which may let the entire team down. This person may be unaware of the full scope of work that he or she needs to do. This is the reason behind such actions.

The developer’s estimate is their personal commitment to complete the task on time.

The manager can surely control estimates manually by checking out every ticket, but this is not what we really want. We need to save time. A project manager can automate their routine tasks by picking the existing tool or even creating one from scratch. This principle is driving the entire IT industry forward.

Now let’s have a look at the simple and elegant solution to the problem with the tasks estimating.

JIRA can do more than you think

To solve the problem, I needed to make developers fill the Original Estimate field before they start working on a task (this is important). I’ve been working with JIRA for over a year now. Thanks to the Atlassian University courses I took, I came up with a solution fast. I assigned a task in JIRA to myself and started as follows:

Prevent developers from moving an issue to the In Progress status until the issue has Original Estimate field filled

By default, JIRA allows you to start working on a task freely, without providing an estimate. So let’s fix this!

Step one. Go to the workflow of your project and find the transition from To Do to the In Progress status.

Step two. Add validation to the Original Estimate in the Field Required Validator. Add the error text explaining why a developer cannot proceed with the task. Apply the changes to your workflow.

Step Three. Testing. Let’s try to move the task to the In Progress status with and without an estimate.

Perfect! Now no one on your team is able to start working on a task that hasn’t been estimated. (Bear in mind that this configuration applies to all tasks going through the transition To Do → In Progress. If you need to set up the estimation required for certain issuetypes, you will need to set additional steps in Conditions).

Conclusion

This simple & smart configuration will help you as a manager to always see how long all tasks take to be completed. Such a condition makes your developers think about the number of tasks taken into work. The estimation process is automated with zero micromanagement!

Previously published at blog.maddevs.io