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 manage software development budget and 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!
If you have questions or need more JIRA tips & tricks, ping me on LinkedIn.
Previously published at maddevs.io.
Top comments (2)
What do you do if there are unforseen problems that maje the estinate unreachable?
Ex: a task is estinated in 10h , but by the 3rd hour the changes break something in anither part if the app. What do we do niw? We cant continue work on this task without repairing the new bug.
Hello.
First of all, if the task has been estimated for 10 hours, then the estimate is very rough, and most probably a developer (or any other specialist) doesn’t have a very detailed and clear picture of what needs to be done. Additionally, big tasks deprive you of short checkpoints and you’ll be aware of implementation issues when it’s already too late.
To prevent cases like this we usually decompose the tasks into small sub-tasks that take <= 2 hours. This allows the team to identify most of the back boxes and system dependencies at the planning stage rather than during the implementation. If there are tasks that are not clear, you can always create tasks for research. Research has to be time-boxed and to have clear deliverables not to waste time.
If the issue has already raised, you have no other option to stop the development and estimate how much time is necessary to fix the bug.
I’d also advise you to work in separate feature branches so that without merging the feature branch to develop or master, another part of the application is stable. Thus, you’ll be able to work on each feature/task independently.
Let me know if further explanation is needed.