Scrum: Is it ok for the design/UX of user story to occur in the same sprint as implementation

Question

I am currently in a sprint (two weeks) where the designer is tasked with defining the requirements and UX of a particular user story.

In the same sprint, I am to implement this design. During sprint planning, I had to take a wild guess as to how long this undefined user story would take.

Today I finally received the design. Unfortunately, the design is incomplete/vague and is more akin to a client's requirements than a design. However, from this, I can still see that I have not nearly estimated enough.

To make matters worse this is not the first time. In the last sprint, the exact same thing happened. I flagged it in our retrospective and the scrum master did not have an answer of how to solve this, instead of saying "that's just development for you". Ironically he gets annoyed if the burn down is not on target...

Now I am going to have to ask/work with the designer to get his job done. This is going to hold me up as I have completed all my other tasks.

So my question is

A) how do you handle dependencies in sprint planning? EDIT: Is it ok for the design/UX of user story to occur in the same sprint as implementation

B) how should I now approach the sprint? Re-estimate the current user story and watch the burndown turn into a burn up and be viewed as incompetent/unproductive? Or add a new task to the current sprint along the lines of "help the designer create a suitable design"

Answer 1

how do you handle dependencies in sprint planning?

Ideally, non-development dependencies are handled before sprint planning, so that you have a good definition of the backlog item to estimate effort against.

But, if that was "just development for you" last sprint, then that was probably going to be just development for you this sprint, so you should really have increased your estimate there and then on upcoming tasks that are in a similar state. This is not being vindictive, and it would be a mistake to let it come over as such.

What it does is shows the uncertainty of estimation without a relatively solid design to estimate against. Perhaps, this will encourage your managers to make sure that a product backlog item is properly defined; but at worst it will cover your back. No one complains when a job come in under-budget.

However, you didn't do that, and now your question is ...

how should I now approach the sprint?

The whole purpose of Scrum as a project management tool is to identify problems early, which you've done. Flag it up to your management, let them decide what to do with the sprint. If they try to blame you, be humble and ask how they suggest you approach similar situations in future, to avoid the same problem, even if you don't truly believe that it's fair.

At the end of the day, these are project management issues, and if you try to solve them within your own bubble, you're setting yourself up to fail. And, when you do, you'll be angry because it'll fall on you, not on the managers who failed to solve the problem when you flagged it up to them.

Answer 2

First off, there is a big difference between dependencies between stories/tasks and uncertainty in the scope/effort of a story/task.

Dependencies are handled by giving the dependent task/story a lower priority than the task/story it depends on and possibly an annotation that it can't start before the other task/story is done.

Uncertainty should be addressed in the planning meeting by clarifying the work that needs to be done on the story. If it isn't possible to remove enough of the uncertainty, the story most likely doesn't meet your "Definition of Ready" and shouldn't be accepted into the sprint.
If, for some reason, the story really needs to go into the sprint, your only option left is to add a risk-buffer to the estimation.

For the current sprint, if you can't work on a story, just report that in the next daily meeting and perform whatever work is possible to reach the overall sprint goal of the team. You might also annotate the story as being blocked and by what.
After a sprint has started, it is in principle impossible to add new tasks to the sprint.
Also, if a task turns out to be more work than estimated, then you don't change the estimation, but you do report faithfully what the progress and remaining effort on the task is.

In the end, in Scrum, it is the team that promises to deliver something. If that promise can't be made, then it is a failure of the entire team, never of an individual within the team.

Answer 3

During sprint planning I had to take a wild guess as to how long this undefined user story would take.

That's the mistake you did. Nobody can force the team to accept a task in the sprint and it's your job to state that the task can not be estimated and accepted in the sprint unless there is at least wireframe (for example). It seems that your scrum master is actually a project manager, which only makes the things worse.

How to approach such task if it's necessary to accomplish it within the sprint (for valid business reasons)? Well, first you have to set deadline for the design, after which you won't be able to implement it. For example: the story is accepted, but the design should be delivered within the first week and implemented within the second. Next, you have to work very closely with the designer to ensure it will be possible to be implemented in the sprint. Scrum assumes cross-functional team and it's up to you to organize your work with the designer. Having said that, if you accept the task in the sprint - which is up to the team to decide - it's up to the team to manage the work in a way that it is completed within the sprint, and to manage the associated risks. You should not wait for another one to finish his/her job to get your job done. It's possible that you are about to reveal a bigger dysfunction in your organization.

Answer 4

Are the tasks about design expressed as stories and what are your team's definitions of

• a story is ready
• a story is done

Each story should have his own requirements and conditions of acceptance, but I think it's a good practice to have a set of rules that are applicable to all stories. For instance, a story is ready if (and only if!): the end to end architecture studies are finished, the design is available, the story has been estimated by the team. Minimal conditions of acceptance could be: the automated test is done, OK and has been integrated to the tests suit, code review is done.

If a story is not ready, don't embed it in your sprint. If condition of acceptance are not meet, then it's not finish.

In your case, the team could decide that to be ready, a development story needs to have a complete design (at least a wireframe, adjust this to your own reality). If so, you can't handle design and dev in the same sprint. The team could also decides that a UX/design story should a least produce a wireframe design. If it's not the case, then the story is not accepted and thus the stories depending on it can't be started.

You should easily convince your managers that having strong rules for ready is a good thing: re-evaluating complexity during sprint is a bad practice. It means the velocity of the team is uncertain and then that they, as managers, have a bad vision of the team's work and of the future.

Answer 5

A Sprint usually starts when the story is clear - at this stage the Product Backlog is established and prioritized. If you started without having the design than it should have been clear what can be done without the design and what not...

If you have to improvise while the design is 'bumping' between the client and PO than your PO has to inform the team about any new features as soon as they appear: this is the meaning of 'flexibility' in Scrum - adapt to the ongoing situation. The Development Team, the Scrum Master and the Product Owner need to communicate permanently, otherwise there is no real-time reaction to change.

Some more training can't harm... Perhaps working with the designer would be an opportunity for you to acquire some new UX skills? ...that's observing the glass being half-full instead of half-empty :))