0

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?

Thanks!

  • As a task on the pbi? – RandomUs1r Jul 25 '18 at 16:29
  • @RandomUs1r yes, I tought that, but what about the sprint planning? Should I include that pbi directly in the sprint? – tincho87 Jul 25 '18 at 16:36
  • 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 Jul 25 '18 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 Jul 25 '18 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 Jul 25 '18 at 17:08
3

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,

  • 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 Jul 25 '18 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 Jul 25 '18 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 Jul 25 '18 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 Jul 25 '18 at 18:36
  • Exactly! I think your approach fits best to my case. – tincho87 Jul 25 '18 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 development processes, not a process in entirety.

In practice there are few different approaches:

  1. When UI design is an integral part of the sprint delivery, it becomes a task under the story much like any development task.
  2. When external approval is required, or the work cannot be completed before commencement of the implementation, delivery of mockup or wireframes can be a separate story delivered in a preceding sprint.
  3. When the UI is part of the requirements, the story should include a wireframe or mock up, ensure these are adequate during three amigos.
  • I think this is good, but I'm having a hard time accepting wireframes as a user story, though. – Greg Burghardt Jul 25 '18 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 Jul 25 '18 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. – Martin Spamer Jul 25 '18 at 17:39
  • @tincho87 I'd have to disagree about value, it is hard to quantify but it is there. – Martin Spamer Jul 25 '18 at 17:41
  • Yes, is hard to quantify, but by itself the UI doesn't do anything...I don't think the UI only as a deliver – tincho87 Jul 25 '18 at 17:43

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.