1

SITUATION: Understand which disciplines are more burdened than others on cross-discipline teams.

POSSIBLE OPTION: When estimating a story, provide a story point estimate for each of the different disciplines. This will then allow the disciplines to understand the amount of work they have specifically vs as a cross-function team.

CAVEAT: Don't use time estimates to solve this problem.

NOTE: This idea scares me a bit, but I'm curious to see how other people have solved this problem. It's something I've recently been throwing around in the back of my head.

EXAMPLE: We have a cross-functional team consisting of (1) game designers (2) client engineers (3) server engineers (4) UI artists (5) VFX artists (6) audio artists (7) quality assurance testers. I need to better understand the distribution of work across those different disciplines during Roadmap Planning, prior to jumping into Sprint Planning. Are our game designers taking on a very large amount of work, while our client engineers are light on tasks? Blanketed story points only provide me a unified view of the work.

Improve this question
4
  • I kind of get the problem but it's a bit vague to me. Could you give an example?
    – mamoo
    Jan 26, 2016 at 10:13
  • 1
    Good question, but doesn't it rather go against the idea of cross-functional teams?
    – Yvonne Aburrow
    Jan 26, 2016 at 11:53
  • I think you have a resource constraint, and you've decided that tweaking estimates are the solution. This smacks of an X/Y problem, but perhaps you could expand on what the underlying process problem is and why you think changing your estimating process will fix your resource constraint.
    – Todd A. Jacobs ♦
    Jan 26, 2016 at 21:41
  • This question could use some judicious editing to avoid sounding like an opinion poll or a homework assignment, and to make it more clear that the problem appears to be that you have some people/roles that are overburdened.
    – Todd A. Jacobs ♦
    Jan 26, 2016 at 21:50

3 Answers 3

Reset to default
3

Ideally a user story is a complete business value statement and the estimate is the total estimate for all tasks and testing that are required to deliver the user story.

What you are describing sails into component territory whereby you write up user stories dedicated purely to one component

  • As a Front End Dev I want make a Button because the Back End dev does not make buttons etc (1 point)
  • I am a Services developer and I will make an API which I throw over the fence to the front end display the data etc (8 points)

This results in compartmentalizing roles and skills rather than making cross-functional user stories.

Ideally the story would be

  • As a Customer Service Agent I want to access the last date that the Customer contacted the Company

^^ This story would require a slice of development including back-end, front-end and solutions architecture consideration.

The estimate should be the total estimate for all tasks/sub-tasks and successful testing. There should not be separate points allocated to design because if the story is not designed then it cannot pass the Definition of Ready to be worked on. A basic design/understanding/outline/wireframe should be ready for the Developers to provide estimates.

Improve this answer
1
  • 1
    +1, because I agree with everything you said about what should happen. I think the OP's problem is something else, but I still wanted to upvote your answer even if it doesn't really solve the OP's issue as currently posted.
    – Todd A. Jacobs ♦
    Jan 26, 2016 at 21:42
1

A common approach is to split sprint planning in to two parts.

In the first part of planning the team works with the Product Owner to allocate stories to the sprint. They estimate in story points as a team and base their capacity on the velocity calculated from previous sprints.

In the second part of planning the delivery team breaks each story down in to tasks some of which may be discipline specific. The team may also do time based estimating on the tasks. Note that these estimates are not being used to work out the capacity of the sprint. Instead, they are used to highlight if any particular discipline is overloaded. Some teams also look to limit the size of tasks to say, 5 hours maximum each. Bigger tasks get broken down.

Once the second part of planning is done the delivery team may ask the Product Owner to consider changing which stories are allocated to the sprint so that there is a good balance of work across the disciplines.

It is worth noting that the more successful teams have team members with what is called 'T' shaped profiles. That is they are very skilled in one discipline but are also willing to work in other disciplines. Teams like this are much more able to deal with the inevitable variation in workload for the various disciplines across sprints.

Improve this answer
0

The most Agile thing is if it works for you, just do it! Also it seems you are not the only one, because the default Taiga Agile project management tooling lets you divide story-points per discipline. They have four disciplines by default: UX, Design, Front and Back.

enter image description here

You can always try it for a couple of iterations and see if it adds value. If not revert back to a single estimation.

Improve this answer
2
  • I really like that you provided a technical implementation for the OP's proposed solution, but I'm not sure it answers the actual question (which is admittedly buried). He seems to be asking how to tell which roles are overburdened, and is proposing splitting the story points as a way of finding out. If Taiga addresses this, maybe you can roll that into your answer and I can upvote. :)
    – Todd A. Jacobs ♦
    Jan 26, 2016 at 21:49
  • Good point, will look into it. :)
    – Niels van Reijmersdal
    Jan 26, 2016 at 21:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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