0

My question relates specifically to project management using Jira by Atlassian.

My product backlog mostly consists of user stories, since this is the most useful to my non-technical product owner.

During the sprint planning user stories are moved into a new sprint in Jira. However most stories often relate to both my solutions backend and frontend, and its therefor useful for my developers to break them down. I therefor wish to create new issues related to the story.

It seems to me that the most "containerized" way to do this, is to create subtasks on the user story. In this way everything is kept within the same visual context in Jira.
However to my understanding "subtasks" represent a piece of a task, that in itself does not represent an increment, that gives value to the PO.
My PO and I agree, that completing a piece of frontend OR backend creates value on its own, so perhaps the backend and frontend should be two NEW separate tasks in the sprint backlog?
Do I link these to the original story? Do I remove the story point estimate from the story and split it up between the backend and frontend tasks?

TLDR: When refining a large user story during the sprint planning, should I create subtasks on the story, relating to frontend, backend, integration etc, and accept that "visually", an increment will only be reached when all the story's subtasks are completed..
Or should I remove the story points from the user story and instead split those points amongst new tasks I create within the sprint backlog, that each relate to frontend, backend, integration etc.

My concern is, that going with the subtask approach will reflect poorly on my burnup-charts since increments are only reached when an entire story is finished.

2
  • 3
    I'm struggling with you and the PO agreeing that completing a piece of frontend work or a piece of backend work on their own creates value. Who is this value created for? Compare that with the value of the story. Is value created for the same person or group? That doesn't seem likely to me. However, there are also other ways to slice this, such as demonstrability or deliverability (neglecting value). I think you need to better define what it means for a Jira issue to be done and who (if anyone) would realize value (and what that value is) from completing the work.
    – Thomas Owens
    Commented Mar 28, 2023 at 15:19
  • "[This] approach will reflect poorly on my burnup-charts since increments are only reached when an entire story is finished." Just so, and quite correctly so. An increment isn't done until it's done. The real question is why that's a problem for you or the team? I'll bet a shiny nickel it's an organizational culture issue rather than a technical one.
    – Todd A. Jacobs
    Commented Mar 28, 2023 at 23:39

3 Answers 3

0

One of the Agile principles is "Individuals and interactions over processes and tools". You are trying to find a reasoning for how to set things up based on the tool you are using and how that tool has tasks and sub-tasks.

Don't do that.

Your Jira board is supposed to be an information radiator. What are you interested to see? What are you interested in tracking? Do tasks help or are you better of looking at the stories? Where do you see the most value? Are you interested in delivering value in the sprint by reaching the sprint goal? Or are you interested in having a nice looking burn-down/up chart?

The items that bring value usually respect INVEST. Finishing the front end sub-task isn't independent of finishing the backend sub-task which might not be independent of finishing the load data from the database sub-task.

Do these things bring value? Sure. Do these things bring value to the end user? Not yet. What can and end user do with a finished database access layer for example?

Keep track of the work with sub-tasks. Keep track of the value with stories. Add the story points to the stories. If not all tasks are finished for a story, then the story isn't finished. Keep it simple.

5
  • Thank you for the answer! If I can ask for a final piece of clarification, what would we then do, if dealing with a very large user story. An example could be building a calendar app or something simmilar: "As a user I want to create a new event in my calendar". This would include frontend for the creation, backend for handling a request, updating a database and much more. Based on our current story points, this story in itself might be a "20" worth of points. This seems like a very big story to put into a sprint backlog (with subtasks), however breaking the story down might not make sense.
    – Markus B
    Commented Mar 29, 2023 at 12:29
  • Big stories hide more things (more required time than estimated, more effort, more bugs, more risks, more unknowns, etc.). That's why you break it down into smaller stories. So that there's less surface for things to hide inside. So try to look at different ways to break it down and you might find a few valuable stories that you can extract from the big one and release one after the other to build the final thing. If you try and try but still cannot break it down, then use common sense and be pragmatic...
    – Bogdan
    Commented Mar 29, 2023 at 19:55
  • ... For example, you might build the backend this sprint, and the frontend next sprint. Then release both. Not ideal. Not desirable. But what else can you do? But do that only as an exception. The rule needs to be something like INVEST. If you find yourself doing this more than once in a full moon, then that's usually a sign that maybe the issue is that the team hasn't practiced enough together how to decompose things. Then you should focus there and work on that. At the end of the day Agile is about "inspect and adapt".
    – Bogdan
    Commented Mar 29, 2023 at 19:57
  • Check also this as a different way to look at things pm.stackexchange.com/questions/33956/…
    – Bogdan
    Commented Mar 29, 2023 at 19:59
  • @MarkusB You need to think differently about vertical slices. Maybe even open a separate question about it. Briefly, though, you might have stories like "add a button to bring up a 'new item' dialog" and "add save and cancel buttons to the new item dialog." Keep them greyed out or add a feature toggle until it's shippable. --The fact that your team members aren't collaborating on building the same feature together is a bigger problem than how you express the stories.
    – Todd A. Jacobs
    Commented Mar 30, 2023 at 5:44
0

Analysis

When refining a large user story during the sprint planning, should I create subtasks on the story, relating to frontend, backend, integration etc, and accept that "visually", an increment will only be reached when all the story's subtasks are completed.

There are a number of anti-patterns embedded in this quested. In no particular order:

  • Large stories violate INVEST. Regardless of framework, stories should be as small, testable, estimatable, and valuable as possible without wandering off into the technical weeds.
  • You should not be decomposing backlog items or features into stories or tasks. That's the development team's job, and it's up to them to figure out who needs to do what to meet the defined goals of a given feature.
  • Assuming you're doing something vaguely Scrum-like, you're missing the forest for the trees. The goal is to achieve the Sprint Goal (or whatever your framework uses as its cohesive objective for the iteration) rather than earning victory points for every step you take along the journey.
  • Agility generally takes a binary view of "done." Either a useful increment of value is produced at the end of the value stream or it is not. An increment is either done or not-done; you don't get partial credit if 80% of everything is 60% done.
  • Sub-tasks might be useful as a checklist for a plan, but if it's not reflective of your Definition of Done for the work item then it's just another way of avoiding active collaboration between the members of the development team.

Collectively, this set of patterns inherently values effort expended rather than outcomes. You get what you measure, so if you continue with this pattern you can expect lots of time and effort to be expended on defining and executing tasks and sub-tasks, but useful outcomes from the process will be few and far between.

Recommendations

JIRA isn't inherently a bad tool, but it is most definitely not an intrinsically agile tool. It's fundamentally a ticketing system, and unless you replace people with teams as the fundamental unit of assignment in JIRA it fosters a culture of "tossing things over the wall" and passing things around by individual assignment. Don't fall into that trap!

JIRA has the concept of epics, features, stories, and tasks. It may also treats bugs, chores, and other such things differently if so configured. That's fine and dandy if that approach adds value to the product, but most of the time it just ends up being used as a time-based task-tracking system. If that's the case, then whether or not there's value in tracking sub-tasks depends on whether tracking sub-tasks is required by the management of a non-agile company culture, or is somehow valuable as part of the development team(s) working agreements with one another.

When talking specifically about web development, it's rare for a meaningful increment to sit in only one of the application's many skill domains:

  • front-end
  • back-end
  • UI/UX
  • database
  • networking
  • QA
  • CI
  • operations
  • etc.

Ideally, your features should represent vertical slices of functionality across all of these domains. It may not have to if the work is to move some widget three pixels to the left, but does that by itself usually add significant value to the product? Probably not.

So, focus on defining features that deliver a useful bit of "what." What new thing should the system do? What old thing should the system do differently? What bad thing should the system stop doing at all? Anything more granular is not really a "feature."

Stories are about how. In order to deliver the feature, how will the development team provide the new, changed, or improved functionality? Who needs to be involved? How will the entire feature be tested to ensure it is fit for purpose and meets the Definition of Done? Those things should be left to the team to decide as long as the features are delivered on a regular cadence more often than not. Any additional granularity should be a process issue for the team to manage themselves.

The triple net here is that fundamental answer to your question is to re-evaluate why you are interested in tracking anything smaller than a feature. If there's a legitimate reason, discuss it with your team and hammer out a working agreement. If not, let your development team hammer out whatever process works best for them.

Teach your team (and your stakeholders!) to value outcomes rather than effort expended. Once you have successfully made this frame shift as a team and as an organization, you can then tune JIRA to fit your process instead of contorting the process around the tool.

0

In Scrum when we talk about 'value' we mean end-user of the product value. We typically define 'done' as when we deliver that end-user value.

It is not unusual to break up a story to make it smaller, but the divided parts should all deliver end-user value.

An example might be a team that works on a product that is used on both iPhones and on Android. The same functionality (e.g. a keyword search) could then be split into two valuable user stories:

As an iPhone user I want to be able to do a keyword search so that I can quickly find the document I need

As an Android phone user I want to be able to do a keyword search so that I can quickly find the document I need

However, it would not typically be a good idea to split the front-end and back-end work into separate user stories. This is because the front-end and the back-end work does not deliver end-user value in isolation. Only together is the end-user value realised.

My concern is, that going with the subtask approach will reflect poorly on my burnup-charts since increments are only reached when an entire story is finished.

This is the exact thing we are trying to achieve. We want to measure our velocity as the creation of end-user value, rather than the completion of technical tasks. This helps us to be a lot more transparent about progress.

For teams that are new to using Scrum this can feel wrong. Why is their hard work in completing the back-end for a feature not recognised on the burn-down chart! The reason we do this is that technical progress is difficult to measure. It is not uncommon for a team to think they are almost done but then discover that there is substantial work left to do. By only tracking progress as 'done' we eliminate some of this uncertainty.

3
  • So in your opinion (or perhabs SCRUM as a framework) value is meant as "value for the end-user". I had currently understood it as "value for the PO". Can you link me to a page that uses this definition? All I can find related to this in the 2020 Scrum guide is the following: "...In order to provide value, the Increment must be usable". This could be interpreted as usable for an end user, but also useable for the PO if he were to fire the entire team and hire a new one (since it would be useful for the new team that the Story has its front-end finished)
    – Markus B
    Commented Mar 29, 2023 at 12:22
  • Some examples of how this is refered to in the Scrum guide: "Each Sprint may be considered a short project.", "The Product Owner proposes how the product could increase its value and utility in the current Sprint.". But the guide isn't the point here. What I was describing was the advantage of measuring progress using end-user value. Whether or not you follow my answer will depend upon if you agree with how useful that advantage is. Commented Mar 29, 2023 at 13:17
  • @MarkusB "Value" can be anything that creates value for the product; it doesn't have to be user-visible, although if you use Connextra-style user stories then it should provide value to the persona defined by "As a(n)..." That's the point of user stories, really: to help you define who wants the feature, why they want it, and what they expect to get out of it. But a user story is not a specification; it's a placeholder for dialog and collaboration.
    – Todd A. Jacobs
    Commented Mar 30, 2023 at 5:48

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.