T-Shirt size estimating

simoncarr June 13, 2021

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?

2 answers

Comments for this post are closed

Community moderators have prevented the ability to post new answers.

Post a new question

0 votes
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
June 13, 2021

So there's quite a lot to unpack here, but I think you've already got a good grasp of most of what I'll be writing next, and don't really need a huge amount of help from us!  

I'm going to pick up a few sentences as starting points:

>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.

There's another conversation I'm involved in this week about wanting to actually renaming project to something else.  I've said "no" (but also how to do it on Server), but not because it's the wrong idea, just because it would confuse people who have used Jira before, and no-one can come up with a better word or phrase!  I have a strong suspicion that at least 95% of Jira installations are using "projects" as not really projects, exactly as you are.  I certainly have not, since, um, well, 2004 when I first got handed a Jira admin account!

>Each department then just throws all their tasks as children under this custom Jira Type.
That's not automatically wrong, it mostly completely right, some places work well with that.  But you say it's not working for you, so it is wrong for you.  I would try to get your main stakeholders in a room together and talk about the reporting you want to be doing, and showing them how it's not working.  I very much doubt they'll turn round and say "not going to help fix this", if you offer them a moderately simple option (have a small handful of very clear issue types, and a rule that your PMs can change them if they spot one that's not right), I think you'll find they will all go with it.

>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.

You have found completely the right place, the Atlassian community is here for Server and DC users just as much as it is for Cloud users.

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

There is quite a lot of stuff in there that I think the way you're suggesting it might break down is pretty much spot-on.  It's certainly better than a lot of the schemes I've seen, and it's definitely better than the scheme I have started a fight about inside my own company.

There is a pile of stuff I could say about how you're looking at estimates, but there's an idea I want to posit first, as it might fix a lot of your issues.  It might also totally fail to fix anything, but there's no way to know without having a conversation about it!  

Have you thought about having separate estimate fields?

Atlassian themselves suggest that when you're doing scrum, you estimate stories in story points, but then log time worked on stories(and sub-tasks, (which you do not estimate because they are part of their parent story), as, well, time worked.

The other idea I've used in these places is to smack people with a dictionary - when it's an "estimate", understand what "estimate" means - it is never "we will do X in time Y", it is a guess at how long something might take.  Admittedly based on a lot of previous experience, but an estimate is never going to be right.  I am actually quite smug about the fact I had a builder estimate stuff to do in my house, and one of the six pieces of work he did fell out as exactly the number of days he said it would take (he's smug about that estimate too!).  It's an estimate, not a commitment. 

Your people are probably mostly right in their estimates (especially if you have PMs moderating their guesswork), but treat it as am estimate in every sense of the word, not a commitment.

simoncarr June 14, 2021

@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?

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
June 18, 2021

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.

0 votes
Carlos Garcia Navarro
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
June 13, 2021

Hi @simoncarr ,

When you say T-shirt estimation, do you mean that you'd like to assign sizes like S, M, L, XL at the project level, and at the same time, link them to number of hours?

Do you want to have an estimation of hours for each project that will include  the total estimation of all the tasks/stories and sub-tasks up-front? While I don't think that you can get an accurate estimation of project hours(and it would be a large amount of time spent on planning!), I think you could guesstimate, and get something to work with. With time, the teams will get better at predicting how long projects normally take (and I always think of Parkinson's Law as something that happens for real).  You could rely on historic data to find out how many hours the projects take and define ranges accordingly....

simoncarr June 14, 2021

 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.

DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
STANDARD
TAGS
AUG Leaders

Atlassian Community Events