0

I have a question about Agile and Story pointing. I was told that user stories should always only be assigned to 1 person for the life of the story. So, you create the story and assign it to a developer, and it stays with that developer til the end.

But, when adding story points, we also consider QA's effort, so if we are considering their effort, those story points are really for more than just the developer that story is assigned to.

That being said, that makes me think that there should be user stories for a developer, and a separate user story for QA, but this doesn't seem right to me.

But, if we are saying a story is 8 points (3 for dev and 5 for QA), when you look at all the stories in Devops (for example), the 8 points goes against the developer, and no points go against the QA resource, so then how do you know how many points a developer actually has, and how many a QA resource actually has?

Sorry if this is a basic question, but it's just confusing to me.

Thanks!

1
  • This is based on a false premise, and is likely being driven by a tool like a ticketing system rather than any useful process reason. Furthermore, "agile" is a set of principles, not a framework or methodology. What agile methodology does your company imagine its currently implementating?
    – Todd A. Jacobs
    Oct 21, 2022 at 0:24

4 Answers 4

1

I don't know who told you that stories should only be assigned to 1 person, but that's not a true statement. Perhaps some organizations work that way, but it's often not feasible. From one side, when building a complex system, one person rarely has all of the skills to finish work of reasonable complexity without any kind of review or consultation with experts in various topics. From another side, the thinking that 1 person works on 1 story inherently precludes pairing and mobbing, which are commonly used and accepted practices.

Assuming that you're using story points, you should consider all of the work necessary to complete the story. For software, that would include things such as UX design, software design, front-end development, back-end development, infrastructure (third-party services, hardware, databases), testing, and so on.

However, questions like this are one good example of why story points aren't useful. Since story points don't equate to anything real, it doesn't conceptually map to how most teams are organized or go about doing their work. My recommendation is usually to not use story points. Focusing on defining the smallest valuable slices of work, delivering those, and tracking the flow metrics like cycle time and throughput to forecast how much work can be done per unit of time is much more realistic. If someone needs estimates, estimating in ideal hours is my preference since those estimates can be summed across specialties, compared to actuals, and don't require thinking and normalization.

1

TL;DR

You may have been told that, but it's generally (although not always) an anti-pattern, especially in agile frameworks. I don't know if I've coined the term, but the practice is called "shepherding," and while there are occasionally use cases for it as outlines below, it's generally a framework implementation smell.

Lifecycle Assignments of User Stores Aren't Required

I was told that user stories should always only be assigned to 1 person for the life of the story.

This is not a requirement for user stories as defined by Mike Cohn, nor is it a requirement of the Scrum framework. It is also not called out anywhere in the values or principles. In other words, it's a practice that you may or may not choose to use (I generally recommend against it), but it is definite not required 1 by any common framework that I know of.


1: Any kibitzers that find a framework (not a tool) that actually requires this practice should post a comment, and I'll add a section for those atypical exceptions.


So, unless you have a really strong reason specific to your organization or that your team has chosen to adopt as part of its self-managing process, I would junk this idea on principle. There are use cases for it, but you haven't posited one except for hearsay.

Shepherding

A Possible Exception: The "Work-Item Shepherd" Practice

One of the few arguments that I would personally accept for assigning a singular person to "own" the work item—as opposed to assigning ownership to the team as a whole—is when you're using an immature implementation (e.g. a Kanban without all the externalities, handoffs, wait states, and other queues fully identified) where someone on the team needs to shepherd the work item through the process.

From a RACI perspective, that person is accountable for helping the ticket move through the process. It doesn't mean they are solely responsible for doing the work it represents.

In a properly-functioning agile implementation, this shouldn't ever really be an issue. From any project management perspective, explicit hand-offs and inter-team dependencies should be minimized to improve flow, so the team should collectively own the work item. However, in less mature processes, someone may need to routinely follow up to ensure that the work item continues to flow through all the essential process stages, routinely update the work item's status, flag the item appropriately if the item becomes blocked in a way that isn't visible to the rest of the team, or otherwise facilitate its completion per the Definition of Done.

Why Shepherding is an Implementation Smell

Despite the foregoing, I'd still consider this practice a little whiffy. It usually indicates:

  1. A ticket-driven system based on individual responsibility rather than collective team ownership.
  2. A tool-driven process where the team is conforming to the expectations of the tool rather than finding or configuring tools that support an empowered team's desired process.
  3. A command-and-control reporting structure where individuals (rather than teams) are accountable for delivery, rather than focusing on a cohesive increment of value (e.g. a Sprint Goal) and a predictable delivery cadence.
  4. An example of the 100% utilization fallacy where the idea is that work is distributed or assigned in a way that's optimized for leveled work distribution rather than focusing on iterative outcomes.

Avoid Cargo-Culting 2 the Shepherding Practice


2: Because someone always argues about definitional things, cargo culting as used here comes from an amalgamation of non-religious connotations relevant to the application of any practices applied without consideration of the underlying purpose or theory. See:

for some of the various ways this is intended to apply to any unconsidered practice, including shepherding.


That doesn't mean you should never use shepherding if it's actually necessary. It simply means you should re-evaluate why you are doing this, what purpose it services, what it's actually measuring, and whether those metrics are intrinsically valuable to the project. I'll bet you a shiny nickel that the answer is because:

  • The PMO requires it.
  • Middle- or executive-management is requiring it.
  • Because "it's always been done this way here."

Whatever the reason, haul it out into the light of day. Reconsider it with a strong presumption that it's solving the wrong problem. If it is, replace it with an experimental metric of some other sort that is more outcome-based. Continue doing that until your outcomes improve. That's the very essence of empiricism and continuous improvement, both of which are considered underpinnings of most modern modern project management frameworks, and explicitly part of Scrum Theory.

0

Story points are not "efforts"; they are numbers that show how big is one relative to the other one. Every role in the development team provides points to a story and the final points of the story are set by consensus ( for example planning poker ). So, for a story, if the development effort is low and the QA effort is high, then an average point will be given to the story.

I am one of the scrum masters that likes the idea of assigning a story to a single developer. A story should be refined enough to be completed by one person. I know, that's not always possible in every team, but in the end, we solve it by creating tasks/subtasks for a story and assigning the frontend or backend ( or also other ) parts of the story to a specific person and keeping it with that person. In the end, even in the dailys, we want to make/see a single person in charge of a story.

4
  • So you add tasks to other developers or QA team members, but the overall story is assigned to who, a Developer? If so, how do you get a clear picture of how many story points are actually assigned to that developer? Oct 21, 2022 at 2:42
  • The developers of the story can decide who to keep in charge of that story and assign the story to that developer. The story points are not assigned to developers, they are assigned to tasks. You have to change your perspective from waterfall to scrum. On scrum, the whole team is responsible for the delivery of the sprint. If you want to measure individual performance, story points may not be the right metric for you. Oct 23, 2022 at 8:32
  • You mean you add hours to the tasks, but those hours should not exceed the number of hours for the story points, right? Ex., if I have an 8 point story (that we equate to 40 hours, the total number of hours for all dev/qa should not be more than 40 hours? Oct 23, 2022 at 17:49
  • Story points do not correspond to hours. With story points, we estimate the complexity, not the efforts. This article may help you to understand the difference: linearb.io/blog/story-points-vs-hours Oct 24, 2022 at 2:22
0

@Nezih TINAS Not sure how to add an image to a comment, so posting a follow-up here on Story points and hours. This is what our organization has documented for this. Maybe this is wrong :-)

Story Points & hours image

2
  • It can be great if you can edit your question and add this image there. Besides, this chart is useful is you remove the "Approx. Days/Hours" and "Unknowns" columns; if you have unknowns, how will you build the story in the sprint; it is very risky, right? Oct 25, 2022 at 2:12
  • It seems that this table was inspired by original source and made more "specific". Such accurate timeboxing can be risky. teamhood.com/agile/story-point-estimation-table
    – VidasV
    Nov 14, 2022 at 9:32

Your Answer

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

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