Feedback

Tag cloud

what's your question? be descriptive.

By: Asked

Should we split story cards with multiple layers?

How do you handle a story card that must be worked on by two developers (e.g. a mainframe and a frontend dev)?

We've encountered situations where the frontend dev finishes his work (using mock objects to simulate the backend) but the backend devs get too busy and don't get to that story. So at the end of the sprint the story is half done. Estimates because useless because we can't tell how much calendar time the story will take to finish, even after it's started.

We've thought of splitting the card into backend and frontend cards. But then they aren't independent, and they individually fail to provide business value (two of the INVEST principles).

Add comment viewed 208 times Latest activity over 1 year ago

NN comments
or Cancel

3 answers

  • 2

d. cooksey

It sounds like you are estimating at the story level. If your stories generally have two separate, but related, components, I would leave the story a single card, but put two estimates on it, one for the front-end, one for the back-end. Task-level estimates, in other words. This keeps the feature consolidated and gives you greater granularity with respect to estimates.

You can also estimate/point everything at the task level for even more granularity.

NN comments
bennett mcelwee
-

That sounds like a good way to do estimation. The problem is that the tasks may not be worked on together. For example, the frontend dev finishes his part of the story on Monday, but the backend dev never gets around to his part at all. So the story card just stays at “In Progress” for the entire sprint, and there is no visibility of the fact that the frontend work is complete. I suppose this reflects the fact that no business value is provided until the backend is done. But still, progress is progress, and I would like the story wall to reflect that.

d. cooksey
-

Do you use task cards? I’m used to seeing story walls where the story is essentially a row header on the left, and the tasks are moved through the various columns. The story card is consolidated with the task cards when development is done and then moved to QA. If you had task cards for frontend and backend parts of the story, perhaps color-coded, you could see at a glance the status of the story and its two main components. I’d be interested in hearing more about how your dev process works, it sounds a bit different from what I’m used to.

bennett mcelwee
-

Our wall has story cards. We don’t have room for a row per story, since we have dozens of stories per sprint. So there’s one card per story, and it moves through the stages as a whole.

d. cooksey
-

Hmm. It sounds like you’re stuck using two cards, since you can’t represent two different positions with the same card. Color coding might still be useful, as you could look at the board and see frontend vs backend progress relatively easily. Another option could be to have two story walls, one for frontend and one for backend.

or Cancel
  • 1

daryl kulak

You are talking about splitting the card horizontally (front-end vs back-end) but I would suggest you instead consider splitting it vertically.

There are three ways to split a story vertically. One is by "path" (to use an old use case term), that is, can you get through one path of functionality only and ignore the rest? An example would be processing by purchase order and ignoring credit card payment functionality. Then split the story by its various paths to make it smaller.

Another way is to leave out error handling at first. Just get an early end-to-end and add error processing later.

Another way is by fidelity. An example of this would be letting the user retrieve a document in plain text, when the ultimate goal is to deliver a PDF.

I would certainly say that you should find some way that one front-end developer should pair with one back-end developer on each card. The only way a card can get pulled from the wall is by a front-end + back-end pair. This may or may not be possible, but I wanted to suggest it. That way, you know the constraints on each card at the time the card gets pulled (i.e. no back-end person to pair with).

Hope this helps.

NN comments
bennett mcelwee
-

Thanks, that’s a good approach, which we have already taken. The trouble is that no matter how thin you make the vertical slice, it still needs frontend + backend work, and we don’t have enough developers to pair them like that without one of them wasting time sitting around till the other finishes. (Besides, we currently have different numbers of backend and frontend people…)

or Cancel
  • 1

tom_83

I think it has to be one story card. Stories should map to features - it shouldn't matter about backend or frontend. If it is one card and it can't be completed until the all tasks are complete, then the team will know that the story hasn't been completed.

Is it possible to have backend/frontend developers work together? That may make collaboration on tasks easier and help spread skills.

NN comments
bennett mcelwee
-

Yes, the literature tends to talk about “developers”, without distinguishing between the web developers, the Java app developers and the Cobol mainframe developers. They can work together to some extent, but there’s only a certain amount of skill sharing that can go on between a bleeding-edge web wonk and a busy Cobol programmer.

bennett mcelwee
-

It’s been suggested that we have one story card, with mini task cards (actually post-its) stuck to it. The mini tasks can be used to display progress, but the whole card can’t move till all development is done.

or Cancel

Question's Contributors

Related Questions