1

I've been doing agile planning for a long time, but always I get to the same question: where should I put the basic UI development tasks? I mean, for example, if we are developing a web app, we need some time to design and develop the basic UI.

Usually, we add extra points to related user stories so we can plan the sprint. Is there a better (or correct) practice?

12
  • As a task on the pbi?
    – RandomUs1r
    Commented Jul 25, 2018 at 16:29
  • @RandomUs1r yes, I tought that, but what about the sprint planning? Should I include that pbi directly in the sprint?
    – tincho87
    Commented Jul 25, 2018 at 16:36
  • 1
    As far as my experience goes agile development model doesn't put emphasis on visual aspects of created software but on usability instead. It means UX over UI. Your UI is whatever the developer ended up using when she or he was adding that much needed button or to clearly communicate the result of that much needed functionality. We do have a separate UI designer in our team, it's better, developers use classes and UI designer makes them consistent and as SASSy as needed, but she doesn't have direct control over UX. Does that help?
    – cprn
    Commented Jul 25, 2018 at 16:37
  • @tincho87 pbis are tasked out during sprint planning (are you thinking of grooming? and if so then no), but as far as planning goes, yes that's where you allocate your time, so that's where you'd allocate 1 hr per developer or whatever to whoever is doing the design task.
    – RandomUs1r
    Commented Jul 25, 2018 at 16:40
  • @cprn mm but what about when you need to plan the sprint? your app is not only made by "code", in most cases it has an UI (where you can apply UX) and your team must spend time doing that. I'm trying to figure out where to put that time. Surely desing stuff will be made by somebody from design, but you need to keep in mind that designer's time is part of the sprint. Maybe I'm misunderstanding something...
    – tincho87
    Commented Jul 25, 2018 at 17:08

2 Answers 2

4

I've found it incredibly helpful to include the user experience design as a part of refinement. I've also found it helpful to consider UX design as part of the product management organization.

Discovery is not only discovering the requirements that stakeholders have for a system, but also how the stakeholders best interact with the system. Although your product managers tend to know about the domain and the different stakeholder classes and how these people intend to use a system, understanding user experience design, user interaction, and user interface design principles are a specialty.

Some of the work is common between requirements engineering and user experience design, such as identifying personas or user classes and creating user flows and user stories or scenarios. However, user experience design uses this to create wireframes and other mockups or prototypes and conducts various tests on what the right interactions are for the different users. The output of these tests is used to refine the criteria used by a development team to build the product.

This does not mean that your UX designers can't operate within a iteration cadence, just like the development team. In fact, it may be beneficial to have them operating on a similar cadence. However, the work that they are doing is actually discovery for future work to be developed by the team in later sprints.

There's also the case where you don't have a dedicated resources for UX/UI design work. In this case, you should consider the design work to be part of whatever backlog refinement activities you have. Frameworks, such as Scrum, provide guidance on how much effort should be allocated to backlog refinement. Some of this time can be the team reviewing, estimating, and decomposing the work while some of this time is used to support product management in the initial development of the requirements, which would include designing the UI and any kind of user testing against the design and mockups.

If you need more than the allocated time for refinement, you should plan this work as part of the iteration. Ensure that you have specific work with specific deliverables laid out so that way the team can estimate the effort per the team's process and plan it accordingly. But do consider that these design tasks would need to be done at least an iteration or two before the implementation deliverable work to allow the designs to be used to inform the estimation and refinement of the work to implement the design,

5
  • It has a lot of sense! So, what I understand is that I should include the UI design/development in a pre-release iteration, right? Because by itself, the UI won't add any value to the customer.
    – tincho87
    Commented Jul 25, 2018 at 17:22
  • @tincho87 I don't know what you mean by "pre-release iteration". Releases have nothing to do with iterations in most frameworks that I'm familiar with. UI design (and user testing) should be done before you code the UI so that way you are coding something that actually meets the needs of users.
    – Thomas Owens
    Commented Jul 25, 2018 at 17:24
  • Sorry, my bad. I was trying to reference "UI design/development" as coding the UI. In this case, should I include the UI coding in a separate PBI or as part of a User Story? For estimation, obviously. (I'll correct the question)
    – tincho87
    Commented Jul 25, 2018 at 17:31
  • @tincho87 The common advice is to have your PBI (perhaps your User Story, if you are using User Stories) be a vertical slice of your application. It includes everything from the user interface to infrastructure. You can then decompose it in ways that make sense for you, but ensuring that you have a potentially releasable increment at the end of the iteration.
    – Thomas Owens
    Commented Jul 25, 2018 at 18:36
  • Exactly! I think your approach fits best to my case.
    – tincho87
    Commented Jul 25, 2018 at 18:46
4

Scrum is not prescriptive of the details of when or how any specific task is performed, it is a framework for the refinement of development processes, not a process in its entirety.

In practice, I've experienced these different approaches:

  1. When the UI design is part of the requirement, the story should include a mock-up or wireframe, ensure these contain adequate detail during a three amigos.
  2. When refinement of the UI design is an integral part of the sprint delivery, it becomes a task under the story much like any development task.
  3. When external review or approval is required meaning the work cannot be completed before commencement of the implementation, delivery of wireframes or mockups can be a separate story delivered in a preceding sprint.
7
  • I think this is good, but I'm having a hard time accepting wireframes as a user story, though. Commented Jul 25, 2018 at 17:26
  • I just edited my question because I was trying to reference "UI/UX design" with "basic UI development". I think the approach #1 is the correct, because the UI by itself doesn't add any value to the product, right?
    – tincho87
    Commented Jul 25, 2018 at 17:35
  • @GregBurghardt I've modified the wording slightly. Being agile is about adapting to what works well to ensure delivery, if you view a story as a discrete piece of work that can be considered done, it should be easier. Commented Jul 25, 2018 at 17:39
  • @tincho87 I'd have to disagree about value, it is hard to quantify but it is there. Commented Jul 25, 2018 at 17:41
  • 1
    @GregBurghardt An alternative way of thinking about this is the user for the wireframe user story is the development team, as opposed to to an application end user. This is just a generalization of the idea that the user in a typical user story might actually be meant to be more specific: a novice app user, a typical app user, a power use or an app administrator. Not all user stories are targeting the same user! Commented Jul 12 at 20:49

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.