nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

What do you do with UI tasks?

SeaninPDX

We just started using Greenhopper for Scrum. When creating stories, we have both UI design and engineering subtasks. This creates a problem when the UI design work needs to happen 1 or 2 sprints before the devs start their subtasks. I've suggested creating "UI Tasks" that are independent of stories but received pushback from the team because they want to see everything together in a single story.

1. Are we not creating stories correctly?

2. Should there be a seperate workflow for UI design tasks?

Perhaps we could link the UI tasks to the story... what is the "Scrum best practice" solution for this? I just want my Rapid Board to reflect reality.... I don't want subtasks on the board that won't actually be touched during that sprint.

Thanks!

Accepted answers

boardtc

Best practice would ask why UI design work needs to start 1 or 2 sprints before development starts?

It may be a case of changing your way of working to work in a more Agile way.

A user story should be a thin vertical slice of end to end functionality worked on together by the team.

All comments

boardtc

Best practice would ask why UI design work needs to start 1 or 2 sprints before development starts?

It may be a case of changing your way of working to work in a more Agile way.

A user story should be a thin vertical slice of end to end functionality worked on together by the team.

SeaninPDX

Hmmm so the ux design normally happens in parallel with development within the sprint? We are still doing ux a couple weeks out because the designers need time to hunt down business requirements. We're essentially practicing "scrum-fall". Not ideal, I know, but I'm up against a giant company that is slow to change. I'm trying to affect change at the team level. Thanks for the feedback!

boardtc

You likely meant that as a comment rather than an answer.

The user stories at the top of the backlog for the next Sprint should be finally enough groomed by the PO and team that they include any "requirement" for that story.

So the acceptance criteria would say what the ui should do rather than how. As the team, including ui design, work on the solution in the Sprint they demo it to the PO. The SM ensures the PO does not try to squeeze in more functionality to the story than what was agreed at spring planning!

Renjith Pillai

+1 for this

JIRA Autobot

I fully agree with @boardtc but in practice that can be really hard to achieve. I am talking from the experience i have from our team. Although we do UI in the same stories it never get's to be REALLY great because there are a lot of User Stories in the pipeline which will require much refactor to the currently made UI so in practice it's good to think about UI well before it's implemented and have that in mind when implementing User Stories to stick to that design. The only way the overall UI design can be sketched way before is if you have a well defined backlog so you know what's in the pipeline at least for next couple of months. All i am trying to say is that code is easy(ier) to refactor but UI is not so you want to nail it down as much as possible from beginning, at least that's my experience.

SeaninPDX

Thanks for the feedback donnib! Yeah we have the same problem. We are currently working towards the 'well defined' backlog...

SeaninPDX

Thanks boardtc Yes, that was meant to be a comment.. I was viewing this on my iPhone and didn't realize I wasn't posting as a comment.

Do you (or anyone else reading this for that matter) have an opinion on creating user stories with several sub-tasks assigned to different team members?

For example, let's pretend I'm building a house and I have a user story that reads: "As the homeowner[user], I want a deck off the backporch[need] so I can grill outside[benefit]"

And that Story would include the following sub-tasks:

1. Design deck (assigned to architect)

2. Choose the correct wood stain (assigned to the painter)

3. Build the deck (assigned to the general contractor)

In this example, it is likely that subtask #1 (design the deck) would happen in Sprint #1 while subtasks #2 and #3 would come in later sprints. The assumption being that subtasks #2 & #3 are dependent on subtask #1 because the painter would need to know where the deck will be (shade or sun), how big it is, etc. before deciding on the correct wood stain.... just like the general contractor needs to know the design of the deck before he builds it...

If we were to move our example story to Sprint #1, the GreenHopper Board would not reflect reality. Only subtask #1 will be worked on during sprint #1.... GreenHopper doesn't allow you to move story subtasks into sprints independently of the parent story, we would then have two subtasks that are not actually 'in progress'..

Not sure if that makes any sense but that is the challenge I am currently facing...

JIRA Autobot

@SeaninPDX the problem you explain above is still covered by the comment @boardtc made. In my opinion you should NOT have user stories which cannot be completed in a Sprint. You need to split work in another way so that work can actually be all "done" in one sprint. This is one of the most tricky part of SCRUM any other Agile methodology. Getting good to split work in such a way that a user story don't take more than a few days to get to "done". Many fail at this. In my team we have tried to use Sub-Tasks but because we did split user Stories up and they became so small there was no reason to have Sub-tasks, developers just owns the User Storie and pass it on in the team if multiple devs needs to work on it.

Fernando Claros

SeaninPDX, I have exactly the same problem. Scrum assumes everyone can - more or less - do the same things, but we develop games, which need really specialized work.

Most of my stories have a mix of Art, Design and Coding subtasks. I have been doing the same as you for years. Our game design must come in advance, because of many reasons, so we are forced to do it at least one sprint before we implement it (often 2-3 sprints).

I have asked around and every game dev I know does the same. Which presents us with the problem of Greenhopper not offering an easy way to split user stories during the planning meeting.

I asked about that here: https://answers.atlassian.com/questions/196981/how-can-i-easily-split-a-user-story-during-our-sprint-planning

I hope it shed some light on the matter for you.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-software

story