1

I want to ask about stories that are not considered done because of missing information from the customer.

I have a sprint with 60 user stories and at the end of the last 2 sprints, I can say that almost all of them are "done" from a development point of view, but I am waiting on the customer for some answers. Then, that will require lets say 2 working days for all stories to be considerered done and closed.

In my situation, what will happen, is that the stories will be shifted to next sprint. The problem is that I am not expecting answers quickly. Things are not working well with the customer.

My questions are;

  1. What is your advice for me in this situation. As I am new to Agile.
  2. How to control resources allocation in this situation, as when I have answers I need the stories to be completed. And this can put my team, as well as me as a leader, under pressure.

Update: a very useful discussion found here on how to address delayed stories https://softwareengineering.stackexchange.com/q/154465

2
  • 1
    The team seems to be missing a useful Definition of Done. These stories are simply not done. You’ll need to work out a process for treating customer acceptance as a separate set of tasks, or reducing per-Sprint capacity to make room for customer delays.
    – Todd A. Jacobs
    Nov 5, 2019 at 16:43
  • Yes this will need a review, i am thinking of splitting/reducinginstead of shifting
    – amr007
    Nov 6, 2019 at 8:07

4 Answers 4

2

If you read the Agile Manifesto and its principles, you will see wording like:

  • Individuals and interactions ...;
  • Customer collaboration ...;
  • Business people and developers must work together daily throughout the project;
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Your problem revolves around these things. Your customer doesn't seem properly involved for an Agile project. If your team has questions and the customer is not around, the responses get delayed. The delays then cause a dependency for development work. Unmet dependencies then turn into blockers.

When work in the sprint gets blocked, and you are not expecting answers quickly as you mention, you have two main options:

  • The first is to work on something else, something on which you are not blocked and don't need to wait for answers.
  • The second is for people to stay idle while they expect an answer. Basically the story is blocked and you just wait until you get the information you need.

The first option seems the most reasonable, but it may have some serious side effects. If you can work on things that bring value then that's ideal, you can do that. But if you work on stuff that doesn't bring the most value, then basically you work on stuff that just happens to be possible to work on. Any stuff.

For example, if you have an ordered list of items in your backlog then you work from the top. But if the first, second, third and forth items are blocked and awaiting responses from the customer, you might work on, say, the fifth. But the fifth is not the most important, the first four are. So basically your prioritization of work gets all messed up. You will eventually turn your backlog into Swiss cheese, full of wholes, while you work on whatever you can that you are not blocked on.

If you then get a response on a blocker, you might have to drop what you are doing and need to start work on the more important things. This causes context switching which is inefficient. Even more context switching when you get back to what you were working on before you got unblocked on the important stuff. This causes frustrations in the team and really messes up your sprints because you can't really plan properly as at any moment you can receive an answer you were waiting for. You might also continue your sprint and work on the stories that got unblocked in the next sprint, but you will just be sliding stories from one sprint to the other.

Now to the second option.

To avoid the issues with the first option, your team could just wait for the information. If they get blocked, they get blocked. That's it. If a story is not properly defined and needs extra information, then they don't start work on it. Basically you try to stick to building what brings most value (i.e. from the top of the backlog) and pause if something is blocking you. This way you don't turn your backlog in Swiss cheese full of wholes and you don't make a mess of prioritization, planning, or of the application itself.

But of course, the second approach looks inefficient because people are paid to do nothing but wait. And here comes the solution to your problem. You need to make your customer aware of this. Communicate transparently that people are idle while blocked by lack of information. Have your PM involve and push for the customer to unblock you. Coach the customer on how to become more involved. Get them more involved.

The second approach is better because it will bring more benefits in the long run. The first approach is worse because it gives you the impression you are doing something now, but in the long run you will just make a mess of things.

Work on getting your customer more involved. If they don't want to get more involved, then they must accept the fact that people won't be able to work at full capacity because they are awaiting answers.

4
  • Thanks Bogdan, your answer sum up the problem and the possible solutions. I would say i agree with you on the 2nd solution that is the best for us and for the customer as well. But looking to my role as team leader not the PM and that i tried alot raise the problem flag and the response i am always getting is lets focus on what we know now, and during UAT with customer things will be clear.. offcourse it will be. But we are simply shifting work.
    – amr007
    Nov 5, 2019 at 8:21
  • Focusing on the solution, i would say i still have stories to work on the back log. But 30% of them have the big storiy points 40-100 each (those will have questions to wait and will have to raise more while work) and the rest of 70% .. each is around 5 to 20 points (and scope and requirements are more clear here and few questions will raise). So i have work to do but as you see the big points are in the stories with lots of blockers. Actually i was thinking of splitting the large stories in a way if at least each one to be 2.. one for the info i have and 2nd one that will be a review for it..
    – amr007
    Nov 5, 2019 at 8:31
  • @amr007, there is a reason why the Fibonacci estimation set goes 20 - 40 - 100 with nothing in between. The stories are becoming so large that an accurate estimate is not possible and it is better to split them in smaller stories anyway. Nov 8, 2019 at 15:08
  • Interesting! .. thank you very much @Bart van Ingen Schenau
    – amr007
    Nov 8, 2019 at 22:26
0

This question appears to be based on a false premise. It requires that you accept unclear work into a Sprint. I'd argue that if you have insufficient detail to get work to a done state and receive feedback from your users or clients, you shouldn't start the work. In some cases, if you can't get full clarity from your users before starting work, it may be necessary to implement the solution based on the clarity that you have and refine it in future iterations.

My preference would tend toward the first option - don't start the work until you have sufficient information. However, doing something is better than being idle, even if that means prototyping and getting ready to demonstrate your understanding. You can consider the ideas of evolutionary prototyping to get something that is demonstrable to stakeholders and could be integrated into the delivered product if it isn't delivered.

1
  • And in fact i was thinking of splitting stories as described to Bogdan above..
    – amr007
    Nov 5, 2019 at 8:33
0

One of the core elements of Scrum is:

Incremental deliveries of "Done" product ensure a potentially useful version of working product is always available.

If a story is awaiting answers from your customer at the end of a sprint then it is not "done". This will then be reflected in the number of story points that get completed in the sprint and so will impact on the team's velocity.

As an example, say a team takes 3 stories into a sprint:

Story X = 5 story points

Story Y = 2 story points

Story Z = 8 story points

If at the end of the sprint you have completed the coding on all three stories, but Story Z is awaiting an answer from the customer, then the total story points completed is 5 + 2 = 7

The unfinished Story Z is returned to the product backlog and is considered as a candidate for the next sprint. It will likely need to be re-estimated once you have the answer from the customer and know what additional work is required to finish it off.

The team's velocity is lowered by not including Story Z, so you will likely bring less work in to the next sprint. This may feel wrong as the team managed to do all the coding in the previous sprint. Really though, it is just an accurate reflection of the team's ability to get work "done".

This may feel unfair. The team has done good work on Story Z, but that is not reflected in the team's velocity. The reason for this is that in Scrum we say completed work is the best measure of progress.

The next step is to try and improve things.

Speak with the customer and explain to them how the team's velocity is being effected by the time it takes to receive answers to your questions. Make the argument that everyone wins if those answers come back sooner. Even better would be to discuss with the customer a way to avoid having to ask questions once work on a story has started.

1
  • Yeah, this a key problem.. and to overcome it i was going to split stories and redistribute the points..
    – amr007
    Nov 7, 2019 at 22:23
0

Don't wait for the deadline of the task to receive customers’ feedback

If you have stories that cannot be finished because of missing information from your customer, this means that you are not exactly agile.

How agile works: The development process has some milestones, in which micro-releases of product are made and feedback from your customer is received. Segment from one milestone to the next one is called iteration (or sprint).

So, not to fail deadline (milestone), try to set a couple of meetings during each sprint. In this case you’ll get timely feedbacks from both sides: your team and customers. Well-timed communication gives an understanding to your customers how the process flows and the ability to make necessary changes for you and your team.

Communication is a great tool that allows to solve all questions by the end of each sprint, without shifting your tasks to the next iteration.

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.

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