How to organise a sprint to accommodate UX design, back-end and front-end work to run smoothly

Nicky,

From your question, I am assuming that you've recently started out using Scrum. The dependency and integration issues you are highlighting were unfortunately always there - Scrum simply makes these issues visible.

A key to Scrum is to ask "what can you complete in a short time frame (sprint)?". And by complete, the intention is to be able to go live in production with it if the business so chooses.

It is the current specialization of your team, and how you are deciding to approach your work (traditional, component-based, phase-view) that is holding you back and causing you pain.

This specialization will not resolve itself immediately - it will take some time. What you can do in the meantime, and will aid in the broadening of skill sets within the team, is to begin looking at your work differently.

What I have found beneficial is to take the deliverable - whatever is actually facing the end-user or customer, and define stories with that in mind. Everything that is needed to meet that business requirement is a task under that story. Do not create stories based on a phased approach (i.e. - back end, front end, UX), because that will simply perpetuate the painful dependency and integration issues you are experiencing.

My advice, for whatever it is worth, is to select something very small, and work to deliver that e-2-e. That means back-end, front-end, and UX all within the same sprint. Start by selecting one field on a report or feed, or one feature on a screen, and have the entire team work on that single item from start to finish. Consider these "micro" efforts like a POC, with the goal to get immediate feedback on the design and direction of the solution. This will allow the bulk of the remaining effort to "piggyback" on that initial story.

Keep your stories very small and focused, and as the team becomes accustomed to working this way, allow them to accept more "small" stories into their sprint.

Good luck.

HI Nick,

I think in only one rhings: one characteristic of scrum team is cross-functional team, maybe you can improve its in your team!!!!

Best,
Gabriel

> How do we organise a sprint to accommodate UX design,
> back-end and front-end work to run smoothly and find
> a way where team members are not waiting on others
> to finish to start their part of the development?

What evidence do you have that these "team members" are in fact working as a team? Do they collaboratively go to where the work is, or are they waiting for the work to come to their individual skill silos? Do they have an appetite for reducing such waste by improving their cross-functional efficiency?

I'm completely on board with Timothy's response. If you are simply apply a waterfall type of process within the Sprint, this issue will continue to plague the project. Often organizations are pushed to begin work without proper preparation. Agile values "Responding to change over following a plan" and not throwing all preparation out the window. There is a lot of UX work that can be done before a project begins that lays the ground work of understanding that allows timely decisions to be made within the Sprint. For example . . . having simple high-level layout, control, color specifications, etc. before beginning work makes a HUGE different. If the Sprint Review event results in a desired UX-based change, it goes into the Sprint Backlog just as any other new or updated request.

Hi Nick,

along the lines of previous responses I would say that your main target should be to add a small (vertical) slice of UX, FE & BE each sprint and to work on all three in parallel. If your team is still in silos it needs to make a gradual (and challenging) effort to step out of them towards a multi-functional team. Of course the expertise will remain with the folks with the most experience in each silo but more people will be able to take part in other areas when the need arises thus reducing the need to wait on others.

Hope this helps,
Michael

I want to add that question:

In my case, there is no workforce balance between backend and frontend. Frontend is slower than backend. How should we plan current sprint? we are doing weekly sprints and backend is always 2 months ahead. I think it is not the issue of scrum but it affects...

I recently encountered this problem as we have FrontEnd (FE), BackEnd (BE), and QA resources. today we break out the points by role and attempt to fill the capacity during our sprint planning sessions. If we didn't do this, you might have a sprint where it's BE heavy and FE developers remain idol. Above you mention multi-functional teams.  I'm assuming the goal is to have developers that can do FE & BE? Realistically, I don't think we are there. We also have QA capacity to deal with. I'd be interested in the tools and techniques used to manage this issue.

today we break out the points by role and attempt to fill the capacity during our sprint planning sessions. 

So, today you are using waterfall practices under the guise of a Scrum Sprint.  

If we didn't do this, you might have a sprint where it's BE heavy and FE developers remain idol.

Or you could break down your Product Backlog items so that work for the entire technology stack can be done together to incrementally deliver a part of the product or feature. 

Based upon my experience, it sounds like the following matches your current methods. I may be mistaken but you will plan out a backend solution, plan a frontend solution based upon the backend solution, build the backend, build the frontend, then let someone with QA in their job title test the whole thing.  Because of the sequencing you probably often find that QA is doing all of their work in the last few days of the Sprint and that any issues they find have to be created as bugs and fixed in the next Sprint. Or you may have a Sprint that is full of QA work that is being done on the development changes from previous Sprints while the developers start working on "the next thing". 

You do not need to have Developers that can work frontend and backend code.  You can have specialities but you do need to recognize that and plan accordingly so that you are able to deliver increments of value every time that are fully developed, tested and ready to be delivered to the stakeholder.  Even if it is not the full feature that has been requested, there should be enough functionality that it can be delivered to the stakeholders for feedback. 

Also remember that not all work done during a Sprint has to be done for the Sprint Goal.  If you have a backend developer that has no work related to the increment, they could do some technical debt repayment, spend time doing some refinement of Product Backlog Items, work on developing a new skill that could be useful for the work that is coming.  As long as that work is not jeopardizing the Developer's ability to satisfy the Sprint Goal and deliver an increment of quality work for the product, why would anyone argue?

you might have a sprint where it's BE heavy and FE developers remain idol (sp?). 

Is it better to ensure that everyone stays busy, or that complete functionality (increment meeting Definition of Done) is being delivered every sprint?



From your post, it seems you are more concerned about the former rather than the latter.   In my opinion, you will continue struggling with Scrum until you shift priorities and focus on the latter over the former.



A quick analogy - no one who buys software off the shelf bases their decision on how busy everyone who worked on it was.   It is quality, functionality, and value that your end-users are looking for.   That is where the focus should be, not on premature optimization.