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"

  • 1
    • Worth mentioning that your question in the subject line is very different from the questions at the bottom of your text. Would be helpful if you edited that to choose one or the other.
      – pdr
      Dec 1, 2014 at 15:22

    5 Answers 5


    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.

    • Thanks for the answer. To expand, my scrum master wants us to be really agile so we can change/iterate on a user story as soon as it has been coded. Therefore he doesn't like too much upfront documentation/design and instead we are to code/plan as we go. Of course this leads me to the situation I have found myself in. The agile manifesto seems to support his stance though. So is it that we are being too agile for our own good?
      – Allan
      Dec 2, 2014 at 13:16
    • As an example, one of our user stories might be "The user wants to be able to play against another human player". In our sprint planning I would probably break this down into a few tasks such as: show servers, choose server to connect to, connect to the server. The designer would then ideally tell me how the servers are displayed, what list filters are available, what happens if there are no servers etc. Of course this list of things is only available to me once he has designed it and in this case is occurring in the same sprint. This list is also subject to change/iteration during the sprint.
      – Allan
      Dec 2, 2014 at 13:26
    • 1
      @Allan: What your scrum master is failing to understand is that, if the designer has to complete their work before a developer can begin their work, that IS up-front design. Making it happen within the sprint removes none of the cost of up-front design but it does make it less-visible AND makes it harder to estimate your development. If you can find a way to iterate with your designer, that's great, make it part of the sprint and make the effort appropriate to a collaborative task. But up-front is OK, as long as it's honest and, preferably, done before the sprint.
      – pdr
      Dec 2, 2014 at 17:15
    • If that's typical of your user stories, I would argue that your stories are too large. Given your example, I would expect to see "user can see list of servers", "user can connect to server and see list of available opponents" as stories.
      – Jules
      Jan 4, 2015 at 10:09

    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.

    • This was a good answer too. If I could mark two answers as correct I would have.
      – Allan
      Dec 2, 2014 at 0:30

    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.

    • Thanks Darhazer. Yes the scrum master is also the project manager. The scrum master has stated that there is to be minimal planning and documentation. Instead we are to build features as we go, with continual reviews during the sprint to iterate/change what was built as determined by the project manger (hence the design and implementation occurring in the same sprint). Having come from a role where the design was fairly solid up front, I am having difficultly adjusting to this code-by-the-wire culture.
      – Allan
      Dec 2, 2014 at 12:58
    • 3
      "... scrum master is also the project manager." - not good. "... minimal planning and documentation ..." - what exactly IS in your Definitions of Ready and/or Done? "... reviews during the sprint to iterate/change what was built as determined by the project manger ..." - that should be the Team's decision, not the scrum master, certainly not the project manager and (if it MUST be anyone) it should be the product owner!
      – Phill W.
      Dec 3, 2014 at 17:47
    • @PhillW. We don't have a definition of ready. We just have a backlog with varying states of detail for a feature. The detail gets fleshed out as we go. Done is officially when the stakeholders sign off but really that's for milestones and it's the manager/scrum master/producer (the same person) who says when it is done. I have now been doing "scrum" for a year, not long after starting I did some self study on scrum as I felt our way of it was odd. The more I read, the more I felt like we are doing "Cargo cult" scrum. But politics makes it difficult for me to do anything about it...
      – Allan
      Dec 5, 2014 at 10:45

    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.


    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 :))

    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.