How to estimate number of days and log daily work in Jira?

Question

I am a newbie to Agile methodology and I somewhat am afraid when I am working on Jira User Stories assigned to me. I have below questions.

1. How to provide estimate for a task or user story assigned to me? I mean what all factors should I consider? There are some stories for which I have to do some research and then develop. While other members in the team provide estimate in days for their user stories, I feel afraid to ask for more.

2. Once I am working on the user story, how should I log my work. I mean, once I am researching for the topic, does those hours also count or only those hours when I am actually writing code. Also, out of the total 9 hours per day, do I have to log 9 hours complete for the day or just those hours in which I actually worked and not counting lunch time and meeting times.

3. If I don't log 9 hours per day, the number of days I will work will surpass the assigned number of days. Is that so?

Any help is appreciated.

Answer 1

How to provide estimate for a task or user story assigned to me? I mean what all factors should I consider? There are some stories for which I have to do some research and then develop.

An approach that works for me is to start with a guess of how long something will take and then add some extra time for:

• Any uncertainty
• Unusually complex tasks
• Tasks with lots of dependencies

While other members in the team provide estimate in days for their user stories, I feel afraid to ask for more.

My advice would be to under promise and over deliver. For example, if you estimate 2 days and it actually takes less than 2 days then people will be happy. If you continually underestimate how much time it takes to do tasks then it will be disruptive and unpopular.

Once I am working on the user story, how should I log my work. I mean, once I am researching for the topic, does those hours also count or only those hours when I am actually writing code.

Everything you do towards completing a task should be included in the estimate. That includes if you have to do research or background reading. Remember that when you learn something new it is valuable to your organisation as it improves your capability. They should want you to be learning!

If I don't log 9 hours per day, the number of days I will work will surpass the assigned number of days. Is that so?

In development we usually estimate in ideal days. An ideal day imagines if you only worked on the one task and had no other distractions. The number of ideal days worked is never the same as the number of actual days worked. It is not unusual for an ideal day to take 1.5 or more real days.

Answer 2

1. This is what I do in my company:

i. Business requirements gathered from manager/product owner (PO) with businesss owner / stakeholders.

ii. PO and developers list down all the features that are needed to implement, from business scopes into features.

iii. Discussion to put high/medium/low priorities for v1, v1,1, v1,2 and so on (Google Minimum Viable Product (MVP)), agreed by business owner.

iv. Product owner/manager/developers and designer to come out wireframes (usually sketches) with those features discusssed earlier.

v. Confirmed wireframe by product owner and developers with stakeholders, the designer comes out final UI.

vi. Create stories, from there you plan how long each stories. If the feature is huge, make it as Epic, split into smaller stories, and plan the time for implementation (based on the developer who is going to do, NOT your manager to decide your implementation time). If you afraid to ask for more, and if you can't finish the task on time, that's your problem. Always be honest and frank to everyone, that's your team, they won't bite. If you fail, everyone fails. So if you finish earlier, pick new stories inside Backlog, and plan your estimation better in next sprint. You can ask for some "buffer" time to do research on certain features which is unclear in implementation for stories estimation, before implementation is officially started.

2. Log ONLY your working hours on that stories. Never log your lunch time (of course!). My previous company was doing "realistic" and "honest" Agile, putting realistic estimation of 6 hours/day for developers (admit that devs as human beings are using the rest 2 hours to watch cats videos, drink water, toileting, flirting, chit-chat, slacking etc).

3. Refer to 2. You should plan your estimation better, based on your experience and ability on spending on your tasks. If you finish all the tasks very earlier than expected estimation time, or over-commit your promise, are considered bad/failed sprint. Improve it on next sprint.