6

We are using Jira for agile PM, but are having problems working with both story points and sub task hours estimation.

Articles like this and this just don't seem to help. The second article has a graphic image which doesn't seem to match the description, so we are quite stuck. I have read through this excellent description of why use both, and I am convinced.

We want to do story point tracking from a high level point of view or can run just with sub-tasks and track estimates of hours but not both at the same time.

-- Edit

The reason we think we need to do both types of estimation, is that the user stories we have cross over three skill groups of staff and have (e.g.) 8 story points. So in tasks estimated, could be 6 days SQL, 1 day .net, 1 day HTML, or it could be 1 days SQL, 5 days .net, 2 days HTML, but I won't know until I estimate tasks. So from a staff planning point of view I (as the scrum master) want to know that I have the right number of user stories / sub tasks / staff mix for the sprint. I cant do that unless I estimate sub tasks.

Or am I missing something?

  • Thx to the people who have put in answers. I have done an edit to the above ... – Marcus D Mar 26 '16 at 8:56
  • 4
    I always dispair when programmers are divided into db, backend, frontend. Its really counter productive – Ewan Mar 26 '16 at 9:18
  • 3
    everyone has a prefered areas but yes. Any programmer hire should be able to cover sql/db, backend code and html/javascript. What if you need to use a new tech, say a no-sql db? Would you fire all the sql guys and hire new people? – Ewan Mar 26 '16 at 9:36
  • 2
    @Ewan ... good question "What if you need to use a new tech, say a no-sql db?", in your model you would have to up skill every team member in that skill – Marcus D Mar 26 '16 at 9:52
  • 1
    Dude, i would expect them to google it and make it work. You expect your sql guys to do both inserts and selects right? – Ewan Mar 26 '16 at 9:58
5

The reason Scrum teams often use story points for estimating is that it provides an effective way to calculate the capacity of a team. They also allow for lightweight forecasting when doing release planning.

The reasons they use time-based estimates on tasks is different. It is so that they can:

  • Spend time breaking work down, which often helps when it comes to implementation
  • Can check that they haven't over-committed in a sprint (it may have looked fine as story points, but the task breakdown may reveal over-commitment)
  • Check that they haven't overloaded a particular discipline (e.g. too much testing work and the team uses dedicated testers)

A lot of Scrum teams start out with this approach as it helps to avoid some of the pitfalls of a team that is new to Scrum. More experienced teams can drop the time-based estimates if they no longer find them of value.

7

+1000 on Daniel's post: Do not use task hours at all.

Hour estimating is something you'll find a lot of the leading agile experts recommend. And then look that the time stamps. I'm not aware of any leading agile voice that still supports hour tracking of tasks. It's been deemed counter-productive to relativistic estimating of story points. The goal of estimating is not to find out how many hours it will take, it is strictly for the team to decide how much work they can take on in the sprint.

We don't care how long one task, or even on story takes. We care if the team delivers what they estimated they would deliver.

Instead of hours for tasks, the general guideline I coach teams on is "tasks should fit into a day's worth of work." This allows easier tracking of status since from daily standup to daily standup you should be completing tasks. This is a GENERAL guideline. Also remember that a "day" is really only 4-5 hours of actual work.

  • interesting points here. I've amended my answer with my problem with it. thx for the suggestion on 4-5 hours / day worked time. We use 6, but practically it is lower, isnt it! – Marcus D Mar 26 '16 at 9:20
5

Just do story points! If you already gained information about your velocity you don't need to estimate hours additionally. Usually we estimate only the complexity of the story and in the planning the team gets the chance to reestimate the story after planning all the tasks. The team then commits only those stories they manage to do in the sprint.

-- Edit

Our team also consist of backend (Java) and front-end (HTML, CSS, ... ). As in your description the stories always have different relations of both skills. Usually the product owner begins to present the stories starting with the most important. After each presented story we ask the team if they can do more or if we should stop here. When one of the skill groups had enough for the sprint we go through the backlog top down and take the next story the others can do. Hope it helps!

  • I've updated my question with the problem I have with not estimating time against sub tasks ... could you tweak your answer please to address this specific topic, pls? – Marcus D Mar 26 '16 at 9:21
  • 1
    I described how we solved a similar problem in our teams. At the moment we only have two skill groups and not three. I could imagine that's even more complicated. What we are just doing is to bring front-end and back-end closer together by more and more letting them doing small tasks of the other skill. We first had doubts, but it's really interesting how they appreciate it and let the team more grow together. – DanielGambal Mar 26 '16 at 9:41
  • I can see the value in cross skilling, but the SQL and .net stuff we are doing is very high end, so not feasible to have the cross skill depth, except on fairly moderate tasks. – Marcus D Mar 26 '16 at 9:55
1

In the case of your team I would say a change to your estimation process is in order. Since you've concluded that you guys are having a hard time making an accurate estimate until you know all the tasks that will be required to fulfil the story, you should come up with them before you do your estimation.

You can do this during your normal sprint planning process, simply describe the story under discussion as completely as possible, perhaps have some quick debate about what the best approach to solving that problem is and then just write down all the tasks (preferably on post-its so you won't need to write them down again later) and base your estimations on the total effort required for those tasks + adequate testing.

Even with this approach, your team should still have a cut-off amount of points where if the estimation is higher than that amount, the story is split into multiple stories. Always try to keep your stories as self-contained as possible while still keeping them easily achievable in a single sprint.

0

It sounds to me like it's your team organisation which is the root of your problem.

If you need to know how much SQL work there is in sprint, I assume it's because if there isn't much, the SQL guy will be twiddling his thumbs and it might seem like you could squeeze in some more SQL tasks.

However, the problem with this is it mucks up the completion of stories. It's very difficult to say an individual task is done unless you can also say the story is done.

E.g., I have a task: write Db for WebPage and Task: write HTML for Webpage.

and Feature: Webpage shows the username.

Unless they work together as a team both the HTML and SQL tasks could be marked done, each programmer assuming that the other task was doing the username feature.

If you get to the end and the feature isn't done but the SQL guy is busy with some other task for a different story and can't jump back to the feature then you end up with lots of open tasks and 'kind of done' features.

  • Your comment " Its very difficult to say an individual task is done unless you can also say the story is done." is very true, which is why we reserve integration time on tasks before they are closed off. We have a small (8 ppl) team across SQL, Neo4j, .net, Spark, R ... so very tricky – Marcus D Mar 26 '16 at 9:58

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.