4

I work on an agile team at the moment where our stories are written primarily from the user perspective as well as testing.

So, for example, we may have a request for a date picker. The story would go something like:

User goes to page x and clicks on date to launch a native date picker

All fine and good, but the problem is how to communicate what that is from a development POV. For example, the issues we'd want to address:

  • we have to support multiple devices
  • even though the user sees a 'native' widget, we're often having to build emulated versions in JS
  • we'd want to be using said widget on many other pages than just x and would want to incorporate variations needed on page y and z into this one component.

We're struggling in figuring out how to best handle this to enable the dev team. One option seems to be for our dev team to build our own component and pattern libraries. We'd then take the user stories and use that data to enhance our own component/pattern library.

Have you ran into this problem and, if so, have you found a way to consolidate the discrepancies between user stories and the concept of reusable component code for the dev team?

Improve this question
1
  • 1
    there is no discrepancy; your process is not agile, it's broken!
    – Steven A. Lowe
    Jun 2, 2011 at 2:20

3 Answers 3

Reset to default
7

S.Lott's answer is good, but I just want to emphasize:

User goes to page x and clicks on date to launch a native date picker

That is not a user story, that is a design decision!

A user story would be:

As a [Texting-obsessed teenager], I want to [schedule a future text message] so that [I can annoy my friends while I sleep]

Format: As a [user role], I want to [do or achieve something] so that [benefit statement]

The story is a placeholder for a conversation between the development team and the stakeholders. The design is done by the development team (which includes the UX people). The creation of reusable libraries is totally outside the scope of the stories.

No offense, but it sounds to me like your entire "agile" development process is broken.

Improve this answer
3
  • 1
    ah! Steven! Yes! That clarifies a whole lot. It seems that stories should be sitting between the stakeholders, and the development team. Right now, stories are sitting between UX and Dev. And are trying to lift way more than they should be.
    – DA01
    Jun 2, 2011 at 4:18
  • Is UX people part of development team ? I thought UX people would mockup screens for stories (in balsamiq or photoshop etc.) and dev team is to implement the mockups. I mean stories should have screen mockups. Or a new story should be created that says "create a mockup for .." if it is to be done by development team.
    – softveda
    Jun 2, 2011 at 8:04
  • @Pratik: The UX people are part of the development team, even if they don't code anything. The user-interface reflects a host of design decisions that must not be made in isolation outside the scope of the stakeholders and dev team.
    – Steven A. Lowe
    Jun 2, 2011 at 8:36
5

Have you ran into this problem and, if so, have you found a way to consolidate the discrepancies between user stories and the concept of reusable component code for the dev team?

"discrepancies" indicates that you might be failing to understand the role of user stories.

They're just requirements. Not design.

You have to understand the stories and then (from them) do design work.

The point of an Agile method is to balance good design against tedious over-documentation of design details that (a) don't matter and (b) will change.

But you still do design, even if you're Agile. You just do minimal, good design. Not over-the-top maximal design.

When you read a user story, you must "take the user stories and use [those requirements] to enhance our own [design library]". That's what "understand" a user story means.

Nothing is wrong with this. It shouldn't be a struggle. That's what you're supposed to do. Otherwise, you're skipping the essential design of usable software. Failure to design is how you accrue technical debt.

Improve this answer
6
  • Well, perhaps the problem lies outside of this process. The dev team isn't the designers on this project. UX is. And there's a disconnect there. UX designs pages. But Dev wants to design components. Perhaps that's the crux of the issue. (I'm a huge proponent of UX and Dev being one and the same, so this seems to validate that even more)
    – DA01
    Jun 1, 2011 at 20:50
  • @DA01: "UX designs pages. But Dev wants to design components". Doesn't sound like a disconnect. It still sounds like UX "requirements" should be feeding some kind of proper design activity that precedes test-writing and coding.
    – S.Lott
    Jun 1, 2011 at 20:56
  • Hmm...do you have an example workflow for that, S.Lott? Sounds like maybe we're missing a step or two.
    – DA01
    Jun 1, 2011 at 21:00
  • @DA01: "Design" would be the step between UX and test cases. It's not a complex workflow. It's just doing what you think you should be doing. "take the user stories and use [those requirements] to enhance our own [design library]". Do what you think you should be doing to create a good design. Do as little as possible and do it as quickly as possible. An Agile method allows you to do design work.
    – S.Lott
    Jun 1, 2011 at 21:03
  • 1
    @DA01: Design is incremental. Do not stop delivery to spend a lot of time on design. Perhaps slow down. But do the design in steps.
    – S.Lott
    Jun 1, 2011 at 21:42
3

Both @S.Lott and @Steven A. Lowe answered your problem. I would not consider the sentence you posted as an user story at all. That's more like a task.

What I would add to those answers is consideration about "component library". Do not start with a reusable component when you first see the piece of code you think can be reused in the future - that is completely bad approach. When developing SW in agile way you are adding the minimum code (satisfying some common programming practices) needed to implement business value. Once a new requirement is being developed you can find that you have already done something similar and only then you can refactor your code and make it reusable for those known two cases. You can repeat this process once you get another requirement again suitable for the component. Be aware that you should have some test suite to validate that refactoring didn't break existing code. Do not add reusability to component upfront - that can be a waste if reusability will not be needed latter or if requirements for reusability will be different than you expected.

Special case is reusability among projects. You should approach this with caution. I would say that second need for the same component still doesn't satisfy investing time into general component.

Improve this answer
1
  • absolutely correct; reusable libraries should come from refactoring, unless they already exist from prior projects or third-party acquisition - and in that case, only use them when and if they are appropriate
    – Steven A. Lowe
    Jun 2, 2011 at 8:39

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.