25

I'm at my 3rd job that is (trying) to do Agile. I've had two past experiences that can be summed up as:

  • one tight-knit small team of 15 doing very incremental sprints (meaning we weren't tackling huge enhancements). All UX and UI work happened during the sprint in a very ad-hoc, collaborative way.

  • one tight-knit dev team with two UI devs, and a UX team that would work ahead a few sprints to get things prepped for us to build fast.

These worked relatively well. They had pain points, of course, but there was a cohesivness to the 'big picture' UX thinking in both situations.

I'm now on one of two SCRUM teams that are working on a huge product. We're running into the challenge of where UX and UI work fits into the sprint planning.

There is no work-ahead in our model. Product owners want a feature, and said feature needs to be both designed from a UX POV and implemented in a UI POV for the devs to build out during that sprint.

Have you worked in an Agile environment like that? If so, where did you place all of the UX and UI tasks within the stories (we happen to be using JIRA)?

What's confusing is that we may have broken down the stories like this:

  • as a user I want to be able to fill out the form...
  • as a user I want to be told if I made a mistake in the form...
  • as a user I want to be informed if the form was submitted succesfully...

The struggle I have is fitting in the UX and UI tasks into the above. It seem to me that every story would need these tasks:

  • UX design ui
  • UI CSS and HTML be built

For each individual story. This seems redundant and a real pain to track. The reason being is that I wouldn't design and implement these individually, of course. The design, HTML and CSS needs to work as a whole.

One suggestion was to create a story called "As a dev team, someone needs to design the HTML and CSS" but this seems rather anti-agile as it's no longer user-focused.

So, had anyone found a solution to this that seems to work for them? Or, like most agile experiences I've had and from what I've heard from others, UX needs to figure out how to work ahead of the entire Agile process and not get mired in the weeds.

Improve this question
4
  • 3
    Are you writing a story book or software? When simply getting something done gets this complicated I'd seriously consider hopping off the "SCRUM" and "agile" bandwagons.
    – Matti Virkkunen
    Commented Jul 2, 2015 at 18:57
  • 1
    @MattiVirkkunen I think they are amazing bandwagons when it comes to getting software built. I think they aren't great bandwagons when it comes to big-picture thinking and planning.
    – DA01
    Commented Jul 2, 2015 at 19:42
  • Thanks so much for asking this. Excellent topic. If I may defend the original meaning of agile, though... what you propose is not anti-agile, which is has been defined as "a group of software development methods in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development, early delivery, continuous improvement, and encourages rapid and flexible response to change." (en.wikipedia.org/wiki/Agile_software_development). If making a card to get work done helps that, it's agile!
    – John Hatton
    Commented Jul 8, 2015 at 16:03
  • @JohnHatton I actually agree with that, though find that that only really works on small agile teams with more narrow focus. At a more enterprise level, I find that it's hard to combine both the 'what' and the 'how' in the same sprint a challenge.
    – DA01
    Commented Jul 8, 2015 at 16:39

5 Answers 5

Reset to default
20

First things first

I don't think UX can succeed in this scenario. A sprint is too short to do both the design and execution of the same feature. You should be out in front of things with the Product Manager defining the work before it ever becomes an engineering request.

If you take that approach seriously (which I've never been able to realize 100%), you end up with Dual Track Scrum: Discovery track feeds the backlog for the Delivery track. Discovery is ideally a partnership of product management, user experience, and software architecture.

Back to the question

If you have to make this work, Jira allows you to link stories/tasks/bugs. In one of my roles I'm on a pseudo dual track team using Jira across the project lifecycle. Here's the process I use to fill up the Kanban board:

  1. Create high level stories. These are based on discovery work done with the Product Manager. I use the job story format. These don't get in the weeds like the examples you listed. Stay focused on user activities.
  2. Create UX tasks as a child of the story. This defines the research or design work you need to make a proper feature request.
  3. Create engineering tasks dependent on the UX tasks. These are usually broken out by the engineering lead on the project based on the preliminary UX ideas. It is rare that these tasks can be accurately created prior to at least some level of completion on the UX portion.

That can all be done very efficiently in Jira. There's also usually some discussion in Jira about the story before the detail can be filled out; especially with remote teams.

When Engineering doesn't play along

From the comments
You mentioned that Engineering doesn't like to be dependent on UX. That's just arrogant stupidity. It's not a question of superiority, but of the proper order of things: planning before implementation. Pose this analogy:

Would you build a database and define the schema in parallel?

If they can answer yes to that, give up.

Improve this answer
4
  • 1
    I agree with everything you're saying! The big monkey wrench for us in your proposal is that dev is not supposed to be dependent on UX. They need to work parallel to what UX is working on. As you can imagine, I find this just plain unfeasible. So goes the life of corporate agile :)
    – DA01
    Commented Jul 2, 2015 at 21:46
  • 2
    Oh the misery. How exactly do they envision building a system in parallel with it's design? No testing or iteration I suppose. Have you posed the analogy of defining a schema while you build the database. If that sounds like a good idea to them, you're out of luck.
    – plainclothes
    Commented Jul 2, 2015 at 21:49
  • 1
    that is a great analogy!
    – DA01
    Commented Jul 6, 2015 at 6:52
  • I add it to my answer: anything to help the cause!
    – plainclothes
    Commented Jul 7, 2015 at 5:50
9

I had very similar experiences to yours (and also been using JIRA for quite some time now).

It goes:

User stories are extremely limited

It seems that every Agile team fails to understand or work with user stories. But for a good reason - a user story capture only a tiny fraction of the problem domain, here's just a couple of things user stories don't capture:

  • More than one persona when applicable (say an accountant and bookkeeper).
  • The pre-condition; eg, "When my bank and statements don't match, I'd like to know the transaction at which the mismatch occurs". There are quite a few arguments there that you should add pre-condition to user stories.

User stories should focus on the subject domain

User stories should really be in the so-called subject domain, meaning in the world of the user without the system. This makes it easy to assign a value to the story. For example:

As a project manager, I'd like to be able to assign a task I've created to someone else.

Notice the the motivation is implied.

Now the moment you start clutter user stories with system domain aspects, things get messy. Consider:

As a user I want to be able to fill out the form...

Which user wants to fill a form? It is the system (or the bank) that needs users to fill forms. I think every user would love to have a form-filler 24/7 assistant.

As a user I want to be told if I made a mistake in the form...

Well too granular, users will also want to "see a form".

as a user I want to be informed if the form was submitted successfully...

Again, well too granular.

So what is a user story?

OK, so one view is that a user story is:

  • Just a title to a more elaborate scenario description.
  • Normally at a high level.
  • Something with a clear business/user value.
  • Ideally in the subject domain.

The big picture

If we adhere to the description above, one way to break down things is:

  • A user story is a title of a focused description of some aspect of the problem domain.
  • A user story is the source to a use case, or part of it.
  • A use case involves an ideal path and alternative (which will include validation errors for example).
  • A use case is distributed amongst various screen elements (pages, panels, and so on).

And then within a scrum setup:

  • Product owner, together with the team priorities and chooses the user stories to be delivered in the coming sprint.
  • Research and design phases take place and an acceptance test is devised.
  • The designer delivers a design document to the developers. Development takes place.
  • QA ensures the user (product owner) is happy with the implementation.

User story deliverance vs UX issues / improvements.

You have to conceptually distinguish between delivering a user story (something with clear value) and UX issues or improvements.

Consider the following user story:

As a user I'd wouldn't like the application to crash if I press Submit twice.

This will be documented as bug - a malfunction of the system - something that doesn't work as expected.

Similarly, UX issues reported or improvements shall be marked as such, and dealt with as such.

User story vs tasks

You also need to distinguish between a user story and tasks (designers or devs). I mean something like "Implement form" or "Implement validation" is a developer task; surely the user story shouldn't deal with such a low level detail.

The problem with JIRA

One issue with JIRA is that an issue can only have one level of sub-tasks. This forces you a particular level of granularity that doesn't always match the team needs. (Personally, I wish JIRA would not have this restriction.)

A proposed solution

  • Distinguish between users stories and UX issues/improvements.
  • Keep user stories at high level. If a user story can be broken down to smaller user stories (as expressed by the users), use an epic instead.
  • Once a user story is picked for a sprint, break it down to subs representing tasks (research, UX design, software design, development, QA); each of these may be assigned to a different team member and will have an estimation.
  • If any assignee needs an extra level of granularity (developers sometimes wish to break the work to smaller chunks), create a new task a make it block the user story subtask.
Improve this answer
4
  • 3
    In regards to the limitations of user stories, look into job stories. I find them much more useful. The context rather than the persona becomes the focus. And a goal rather than a solution is the request.
    – plainclothes
    Commented Jul 2, 2015 at 21:54
  • So, the issue is we're probably just doing a lot of things wrong. For example, our team didn't pick a user story for the sprint, but about 15 of them. Granted, these are actually perhaps more task based ala "build the form" and "now build the form validation". The catch is that at that level, every story ends up needed UX tasks but these tasks can't really be completed in isolation of the other stories.
    – DA01
    Commented Jul 2, 2015 at 22:05
  • First, I wouldn't call these things 'wrong' - it's a complex business with many scenarios and it's more important to identify issues like you did and devise solutions than stick to any method out there. On top, JIRA has some conceptual issues and Agile itself can be insensible to employ sometimes - I often encounter a request for a localised design when I know fully that the whole user journey is full of issues.
    – Izhaki
    Commented Jul 2, 2015 at 22:14
  • Anyhow, you should define the level of granularity you are working on - too much and things can easily spiral out of control. I wouldn't pick something like 'build the form' in a sprint - this is just a means to achieve a higher user goal, which is really what needs to be picked. If a UX design requires looking at, say, 5 pages. The whole design should be delivered as one, and should be implemented as one. How individuals break down their work is their business. From a product owner or manager perspective, I just care that it'll take a developer X days to deliver the big thing.
    – Izhaki
    Commented Jul 2, 2015 at 22:19
3

Focus first on the user story. As it stands there is no user value inherent in the first story as it is written. Try rewriting it from the User's perspective (and consider that User's don't want to fill out forms but form fills are necessary in order to get something that they want). Attach a simple ux workflow created by ux in collab with dev. The other 2 stories can be considered as part of the overall ux and acceptance criteria.

Improve this answer
1
  • 1
    I think that's a valid way to look at it, though the current challenge is how does UX track specific tasks from design to HTML/CSS creation in the context of broad stories that have to be, by their nature, chopped up into small chunks. (Personally, this is why I feel UX needs to happen outside of the Agile task model..)
    – DA01
    Commented Jul 2, 2015 at 19:43
2

If your company is like ours it might still be relevant ;)

"a UX team that would work ahead a few sprints to get things prepped for us to build fast."

That is exactly what we did, when I was on a large project in a UX team of up to 6 people, and up to 4 development teams doing Scrum.

Firstly a lot of the UX work - e.g. research of customer & users requirements etc - has to be done first in order to generate the Stories. So this description starts from a point where a lot of Stories had been captured and needed refinement.

The UX team would work in advance of the dev teams (we aimed for a couple of sprints but we were lucky to get one sprint ahead - 2 weeks), and the story would be marked as 'Ready for dev' when the design was ready.

Any stories that affected the UI went through the UX team first. We also used JIRA. For the simplest stories we would just write comments on the JIRA describing the UI change needed e.g. ("add another field to form x in the same style as field a"), and for stories which needed more work - mockups / more research etc - we would create a Subtask for this as a child of the story. (It might be worth mentioning our Stories weren't at the highest level by this point - all Stories were linked as children to Epics, so everything could be tied back to the big picture.)

The database analogy from @plainclothes is an excellent one - in fact we ended up with a database team who worked exactly the same way as the UX team; the story was only 'Ready for dev' when they had done the schema design.

Our way of working just gradually evolved from trying to be another Scrum team, to just doing what we needed to do to feed the dev teams. Our board looked a bit like a Kanban one. Recently though I found that the way we were working is actually recognised - this diagram might be good to wave at managers: http://www.scaledagileframework.com/

It took us a while to get there and things weren't always smooth, but I really felt overall this was a good way of working and would recommend it again.

Improve this answer
2

The following may also help if you are truly agile:

Design as a Kanban Stage

Instead of making a card for UX/UI design vs. coding, we treat design as a stage in our Kanban boards:

Open --> Ready for Design --> Ready for Coding --> In Progress --> Ready for UI Review --> Ready for Code Review --> etc.

Note the "Ready for UI Review", which gives me the chance to verify what was actually built before the card goes into "Ready for Code Review".

Now, this doesn't solve your problem if your team can only have one set of cards active at a time; the programmers would be sitting around waiting for the designer. For our team, I simply plan a couple iterations at a time, so I can get started on design for the next iteration ahead of time.

True Agility

Tweaking the process is consistent with the true meaning of agile, before the certification industry managed to narrow it down to a set of specific rigid practices. True agile development requires being pragmatic, flexible, and continuously learning, evaluating, adapting. See Dave Thomas' defense of true agility.

Improve this answer

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.