0

We are a small software agency (15 people), currently using Jira, and implementing some Scrum practices more rigorously.

But we're struggling with understanding how User Stories would help some parts of our dev process, particularly when backend/frontend teams work asynchronously.

As our allocation of people to projects may vary from sprint to sprint, it's common that one sprint there may be only backend work, and then the next only frontend work. So the User Story may be complete only after both areas finished their part.

We're aware that this is not a good practice, but for the size of the company it seems useful.

Problem

An US may take several sprints to be finished (because of async work between frontend and backend). I'm aware that this wouldn't be a good practice.

Possible solutions

1- Not using US at all (how we're currently working). So we're using only Tasks (like implementing an endpoint for backend, or implementing a view for frontend), and Epics directly.

Cons:

  • Developers loose sight and ownership of the big picture of the feature.
  • We can't measure feature/US deviation.

2- Avoid our async practice between specializations (backend/frontend). We should make sure that in every sprint we have a "full-stack" team that is able to complete the US.

Cons:

  • It's common that we have idle people when transitioning between projects. For example, it's useful for us to work some backend tasks before the Frontend team start.

3- Use User Stories, but it may be finished after several sprints.

Cons:

  • They may be only completed after several sprints.
  • It's not clear who is the owner. Should it be the last person in charge? Or the PM?

I'd would appreciate some thoughts on this.

Thanks for your help

  • 2
    Work towards cross-functional or feature teams, and don't fall prey to the 100% utilization fallacy. You're creating dysfunction because you fear "idle hands," not because your current system creates value. – Todd A. Jacobs Jan 21 at 21:21
5

TL;DR

This is fundamentally an X/Y problem. The unspoken premise missing from your original post is presumably that your clients don't want to pay for "idle" resources, but that's really just a straw man argument that obscures the lack of collaboration between your teams and the I-shaped people that compose them.

The team needs to self-organize around a predictable delivery cadence that provides a potentially-shippable product increment every single Sprint, and meets its Sprint Goals the vast majority of the time. If you're not doing those things, you're not actually doing Scrum.

If you have a very large project, you probably need to look at some form of scaled agile framework such as Scrum-of-Scrums, Nexus, LeSS, or SAFe. That won't really change anything below, but it may address some of the integration and collaboration problems you're having with multi-team workflows.

JIRA is a Tool, Not a Framework

Your question includes the tag. JIRA is a ticketing system, not an agile framework. While it may help you track work or meet reporting requirements, it isn't a substitute for a properly-implemented agile project management framework.

Allowing JIRA to drive the implementation of your Scrum framework, rather than supporting the framework's requirements, is a well known anti-pattern. Once you've identified the necessary workflows to meet your project's objectives, JIRA should be configured to support that workflow. Doing it the other way around is tantamount to the tail wagging the dog.

JIRA can certainly support Scrum implementations. However, if you find the process contorting itself around JIRA (or any other tool), then the tool is the problem. Either find a way to integrate the tool with your desired workflow, or discard the tool for something that's a better fit.

Respect the Time Box

Your question is tagged with , so all Product Backlog Items (PBIs) pulled into the Sprint Backlog are expected to fit within a single iteration. If the stories won't fit, they need to be deferred, refactored, split, re-scoped, sliced differently, or otherwise reworked so that a cohesive Sprint Goal can be delivered at the end of each Sprint.

The goal of a Sprint is to deliver the Sprint Goal. If you don't have a clearly-defined goal, or can't routinely deliver an increment of work at the end of each Sprint, then you aren't really doing Scrum. That may be okay, but please recognize that what you're currently doing is really just Scrum-But at this point.

If your teams can't or won't follow the framework's requirements, then Scrum may not be the right framework for your project. No one outside your organization can decide that for you, but some soul-searching about why your teams are doing ersatz Scrum, and whether that's leading to the results your company wants, is probably in order.

Co-Dependent Teams and Excessive Rework: Just Say "No!"

Features can certainly be split into front-end and back-end pieces, but it will require you to think about the problem domain and the solution space differently. It may also require you to stop thinking of your teams as delivering on a single, cohesive increment.

By splitting work across teams, work often becomes a game of ping-pong rather than a fully-collaborative effort. For instance, the back end team builds a model, the front end team builds a view to expose the model, and then the teams toss work over the wall to one another to refine the separate implementations.

This can certainly work, but each step or hand-off in your process creates friction, overhead, and potential rework. In an iterative process, refactoring and rework are expected as the product is refined over time. However, baking the need for refinement into your process creates a layer of co-dependency between teams that usually leads to externalizing dependencies rather than active collaboration. This creates needless technical debt and slows velocity for no discernible gain.

Just like test-first development involves testers before, during, and after code is written, back-end and front-end work should involve both types of work ab initio so that the final product reflects the emergent design of both aspects. Otherwise, you create a scenario where one team or the other builds something without taking the other team's skills and requirements into account.

  • "Here's my model, build a UI around it." This constrains the solution space for the front end developers, and often requires rework by the back end developers to accommodate front end changes.
  • "Here's a UI wireframe. Build me a back end to match." This constrains the back end solution space, and often requires contortions that abuse SOLID principles or require ugly hacks to support UI elements that aren't natively expressed by the current domain logic.
  • "I did this thing last week. Please make your stuff match this week. Then I'll have to fix a bunch of stuff that you break next week." This obvious anti-pattern needs no further explanation.

In short, iterative development implies a certain amount of rework and refactoring, but ping-pong development just slops on an unconscionable amount of it for no demonstrable benefit. Hence, the agile focus on collaboration over rigid process and work silos.

Clients Value Outcomes, Not Effort

The final thing to consider here is that transparency (a core Scrum principle) doesn't require over-explanation or whitewashing of the process. Agile organizations don't need to cloak what they're doing in ersatz productivity (more correctly pronounced "busy work") to justify what they're doing.

Scrum is based on fitting variable scope (the Sprint Backlog) into a fixed time box (the Sprint) with a predictable run-rate (the average cost for each Sprint) to achieve milestones (the Sprint Goals) that lead to an acceptable product. In other words, a Scrum Team costs X dollars per Sprint, with an estimated N Sprints to reach a release target. The project sponsor gets a chance every single Sprint to evaluate the project to determine if it's "good enough" as is, whether more Sprints are required, or whether the project should be killed off as a sunk cost.

The client should focus on the delivered increments and product goals, and can weigh in on whether the running cost of the project is delivering sufficient value or not. Focusing on the utilization of team members, or in fact on anything other than the incremental delivery of business value, is inherently non-agile. It's a holdover from Theory X management, and selling agile projects based on other than predictable delivery of observable increments of value (such as per-person labor costs) is largely self-defeating for everyone involved.

Clients should care whether the weekly run rate is delivering sufficient value for their purposes. Clients should not care whether Alice and Bob are on the same team, different teams, or snowboarding in the Himalayas, so long as the product increments are routinely providing sufficient perceived value for the money spent.

The outcome of each Sprint is what delivers potential value. The Scrum Team's internal process should be largely irrelevant. If that's not the case for your project, neither the organization nor the client have been sufficiently educated about the trade-offs inherent in agile processes.

  • TIL: I-shaped people = people with deep technical specializations ... T-shaped people = people with broad technical specializations. medium.com/@warren2lynch/… – hamena314 Jan 22 at 12:53
0

There are some engineering practices that can make this problem easier to solve.

For example, the back-end developers can rapidly build stubs and mocks to let the front-end developers start their work.

Consider a team working on a new search feature. The steps you can go through might be:

  • Back-end devs create a search API
  • Back-end devs create a stub/mock that acts like it is returning search results
  • Front-end devs get to work on the UI implementation using the stub/mock
  • Back-end devs work in parallel on the server-side implementation
  • When the back-end devs are done they swap out the stub/mock for the real code
  • Front-end devs carry on until they are complete and don't get blocked

This kind of approach can make it a lot easier to run a full-stack team that delivers a potentially releasable increment at the end of each sprint.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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