We kick started an Agile development team with a Sprint 0, that had some architectural runway tasks in it (like setting up the environment, etc.). We planned a Sprint 1 with 2-3 user stories (there are 4 devs on the team). At the end of Sprint 1, none of the stories were closed. Some of the arch. tasks from Sprint 0 were dragged in, and they weren't closed either. We started Sprint 2 with some user stories, and we're mid-way through it, and no stories have been closed. I'm at a loss at what's happening, and would like to identify the problem of why we're not producing any value. Obviously the team is working on something, and claims there are no blockers during standup.

What would be an effective way to problem solve this issue with the team? When I asked them during Sprint 1 retrospective on what we can do to improve, they didn't really have any ideas. I would like to tease out some ideas from them.

  • This is probably an iteration planning problem. Actionable PBIs should never be larger than one iteration, so you may want to facilitate a discussion on sizing and decomposition, including some practical exercises and techniques.
    – Todd A. Jacobs
    Commented Jan 24, 2018 at 19:16

3 Answers 3


Sounds like you need to ask the team. They aren't yet sufficiently reflexive to be able to diagnose what is happening, so be more indirect:

"We estimated this story as being X storypoints, which we thought meant that it could be done in our first sprint. It's still not done. Let's unpack it a bit and see where we went wrong."

That will surface some issues that hadn't been considered, or provide an entry into a conversation about the =details= of what is going wrong. People can usually grapple with the trees--if you find the right trees. That conversation can also help you get the team to begin to reflect a bit.

The attitude you want is not, "we said this would be done, but it's not done, so get on it/what went wrong," but "we said this would be done. It's not. Clearly there is more to it--let's take a look and see if we can understand what is happening here." No blame, no guilt, just getting better at working together, collaboration: "what is blocking us/taking more time/what did we miss accounting for."

That's a start, at least.


Do you have a coach experienced in modern software development? If not, one is needed. If so, they aren't doing their job.

There are a multitude of possibilities creating the outcomes you are seeing and various possible remedies. Context is king when it comes to identifying, analyzing, choosing a solution, and evaluating the results.

On a more practical note for the team, learn about techniques such as vertical slicing, pair and mob programming, test-first mentality, etc. Some quick links: Vertical Slicing, Pair Programming, Increment, Test Driven Development.


It seems that the tasks are too big to be done. I would suggest that you think about the "INVEST" term (independent, negotiable, valuable, estimable, small, testable).

Most of the teams miss the "small" word.

One more thing you need to consider while practicing retrospective is the actions; it is not only what went wrong or what needs to be improved, you need to produce an action list and link them with resources and time.

If you practice these two points, things can move smoothly and by time you can add more practices such as kanban board, burn up/burn down charts and others.

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.