6

First of all, let me apologize if I make some writing mistakes since english is not my native language.

I'm currently working at a UX company as a front-end dev and I'm having some problems trying to understand agile development properly. Let me give you some context about our work environment before making my question.

My actual company was focused mainly on UX consulting, creating the information architecture, designing the applications and creating the views in a very old-fashioned way (creating static pages with lots of contextual CSS and jQuery, instead of creating modular systems that allows you to create such pages). Then the "views" would be given to the client and a third-party company would integrate that code with the client's back-end. Currently what I've got as a developer is a design of the different views (full pages) and their different states and I have to code them.

Lately they've got some clients that wanted their projects/UIs be created with Angular so they hire me to modernize their workflow, since I have experience creating Angularjs applications in a more component based philosophy. The problem is that I've never worked in a scrum/agile environment and we are thinking about implementing it so I struggle with some concepts.

What could be a user story in my case? I mean, I'm detached from the product design process. What I've got is some .psd files that needs to be transformed in to a web application, so I'm not sure how I should define user stories for the development team. Creating a component could be a task, but I cannot map User Stories to an isolated process of coding a UI.

Again, I'm just starting out with agile development and I'm sure many flaws can be spotted on my thought process, so I hope you could understand what I'm trying to say.

Thank you in advance.

Improve this question

2 Answers 2

Reset to default
5

You ask a pretty large question, so forgive me if my answer is a little too broad. It sounds like you're starting with the .psd's and then your development team will be acting as an agile team from there to delivery. This may not be ideal, but I'll save that for the end.

Given your circumstance, I want to first clarify that while agile promotes measuring progress in working end-to-end software, this may be confusing for your group. It sounds like your end-to-end is all in HTML, CSS, and jQuery/Angular. If you then hand it off to some other company to do web services or something, I wouldn't try to incorporate that into your idea of Done. Your end-to-end means the functionality of the page and the JS works properly and you can prove it.

As for the stories construction, the key is to focus on value delivery, not artifact creation. For example, artifact creation would say:

As a user, I'd like a login page so I can log in.

and it would have acceptance criteria like:

I can log in. I have a forgot password link ...

Focusing on the capability would be:

As a registered user who forgot his password, I'd like to be able to provide my email and have my password reminder sent to me.

The idea is that instead of your work focusing on recreating the .psd, you are trying to create functionality using the .psd as your guide to how it should look. Incidentally, you will have recreated the .psd by the time you're done, so don't worry about losing something there.

How it could be better: You can run into some snags with your designers still working with the approach of mocking up a psd and handing it off. You are probably already aware that Photoshop and browsers render graphics differently and incredible amounts of time can be lost trying to match them. In addition, if a piece of functionality flows through many screens, the designers may have completed only half of the screens you need to deliver the functionality.

I've seen teams really struggle with this dynamic before and have much more success moving to a system where there is a standard stylesheet for web components and using rapid prototyping for layout.

Improve this answer
4
  • Great response Daniel, it's very enlightening. You figured out correctly our way of working. Thinking about my definition of done was helpful. About the last part, do you have any good reading/guide about that specific workflow that delves into de issue? I would appreciate it so much. Thank you very much, your insight is very helpful.
    – user21377
    Dec 3, 2015 at 15:46
  • I don't have any go-to reading, but I took a look around. I feel like this one does a good job of describing it: romanpichler.com/blog/agile-user-interface-design And this one talks a bit more about breaking up work: blogs.balsamiq.com/ux/2013/02/06/… The second one especially is a little too prescriptive in what you're building for my tastes. I think it's focusing too much on building exactly a thing instead of solving a user need, but as long as you keep that in mind I think it's a good article.
    – Daniel
    Dec 3, 2015 at 22:30
  • Adding to "How it could be better", I would also recommend (if you aren't already doing it) is having your team be cross-functional; have the visual designer, UX/info architect, front-end devs like yourself all sit together and have shared understanding and goals around user needs, plans, results, process, etc. Even though there might not be much overlap in skill sets, working closely and collaboratively at all stages (that means you being involved in early concepts through to delivery) is time well spent.
    – Jeff Lindsey
    Dec 7, 2015 at 20:11
  • As a frontend dev, I am having this same struggle. Mockups should be driven by user stories, but i often experience the opposite approach. I will take a look at the above articles and see if they help.
    – Emma Earl Kent
    Aug 8, 2019 at 15:57
2

I realize this is an older question, but I think it's still relevant given my struggle to find an answer to your question. Here's what i've come up with for some best practices for writing frontend tickets/tasks:

  1. Mockups (which often drive frontend tasks) should be done after user stories (who, what, where, why) are written. These stories should explain value to user, which is important context for frontend tasks.
  2. Frontend tasks/tickets should be part of user stories and driven from users stories, but an individual frontend ticket or task does not need to have a user story.
  3. Frontend tasks may be better described with functional descriptions and acceptance criteria instead of user stories

Resources: https://balsamiq.com/learn/resources/articles/userstories/ https://builttoadapt.io/this-is-what-my-user-stories-look-like-50c7b127bb26 https://en.wikipedia.org/wiki/Feature-driven_development

Hope that helps.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.