T-Shirt size estimating

Question

I want to be able to give my customers a T-Shirt size estimate of the hours required to complete a project up front in Jira. In fact, I have to, this is demanded by the company I work for.

It's worth noting that we don't use projects as projects. We use Jira projects to represent business departments and we use custom Jira types to represent a project. Each department then just throws all their tasks as children under this custom Jira Type. This one level structure makes it difficult for me to keep track of the work going on in different areas of my specific department.

We are also using the Jira On-Prem data centre version of Jira, however I could not find a public forum for this product, hence posting here.

So... I want to setup this structure for the work breakdown I put under the customer Jira Type.

- Custom Jira Type (represents a project)

- Epic (Represent a delivery stream in the project i.e. micro-services team)

- Project Management Task (This is the level I will estimate at i.e. 20h)

- Sub Task 1 (users log work at this level, but don't provide an estimate)

- Development ( Epic)

- API Development - Task (This is the level I will provide an estimate for i.e. 150 h)

- Sub Task 1 (Users log work at this level, but don't provide an estimate)

- GUI Development - Task (This is the level I will provide an estimate for i.e. 300 h)

- Sub Task 1 (Users log work at this level, but don't provide an estimate)

If I work in the way the Jira seems to want me to, i.e. users estimating how long something is going to take them when they create the task, then I can't provide an estimate to the customer through Jira until the project is completed.

If I Estimate at the task level in Jira (As I am doing in the example above), then the customer can see up front in Jira the original estimate for the project in big chunks. I.e. Project Management, API Development, GUI Development.

The problem is that if the users creating sub tasks add an estimate to the sub task, then it rolls up into the estimates I have already given. I don't want this to happen. However, If the users only log work in the sub tasks and don't provide an estimate, then the work logged does not impact the "Estimate Remaining" time of the parent tasks.

The benefit of the structure above though is that I can see at my department level (micro-services) how much work has been done. I can also drill down into each of the sub work streams my team is working on and see how many hours each team has discharged.

How can I get the best of both worlds. T-Shirt sized up front estimating, while allowing users to just log hours with out an estimate in sub tasks, and still have the hours logged impact the higher level remaining estimate?

Nic Brough -Adaptavist- · Answer

You can still do exactly that, there's nothing wrong with the idea.

But you need to separate out "sprint estimate" from "time estimate".  Even if they're both estimated in the same units, they are different principles.

A sprint estimate is only useful for estimating sprints, which are based on the list of things you committed to doing (long story short - things at the issue level, such as stories, not sub-tasks).  Your time estimates, and logging, can indeed apply at both issue and sub-task level, and roll-up, but it's not the sprint estimate and is handled differently.

Jira has only one "time tracking" field, so you're a bit stuck there, but even if it allowed multiple ones, they would still be totally independent of each other.

So, without coding, the closest you can do is "sprint estimate in hours" and then use the time estimate for the actual time logging on issues and sub-tasks, and then eventually billing too.

simoncarr · Answer

@Nic Brough -Adaptavist- Thanks for your detailed response.

The reason we use hours rather than points is because the customer will be crossed charged between departments for these hours, albeit wooden dollars in company terms, but nether the less, they need to know the hours.

I would like to start running sprints as well, where I agree story points would be better in organising sprint content.

The Exam question remains, however, how can I can log work on sub tasks without adding an "Original Estimate" and the hours logged still impact the rolled up "Remaining Hours" at the "Custom Type" level?

simoncarr · Answer

Hi Carols. Yes I use T-Shirt Sizes like S, M, L, XL. Each of these T-Shirt sizes then represents an Estimated number of hours + an element of risk. So before I start work I have already given the estimated hours to the customer. The total hours estimated for the project is then further broken down into Sub Categories containing a fraction of the total project estimate, as shown in my example.

I think the title may have thrown you off the actual question I was asking, that is my fault. The quality of the estimating is not the issue here, although I agree it can always improve. We provide a single estimate to the customer of the total project hours before the project starts. As you see in the example structure above, that total estimate is broken into sub levels with each parent level having a portion of the total budget.

The Exam question however is how can I can log work on sub tasks without adding an "Original Estimate" and the hours logged still impact the rolled up "Remaining Hours" at the "Custom Type" level.