How can we avoid finishing all stories on the last day of a sprint?

Question

I am the Scrum Master for a team that has completed two sprints. For Sprint 1, the burndown looks like:

Day 1: 70
Day 2: 70
Day 3: 70
Day 4: 70
Day 5: 13

For Sprint #2:

Day 1: 90
Day 2: 90
Day 3: 90
Day 4: 86
Day 5: 86
Day 6: 86
Day 7: 86
Day 8: 86
Day 9:  2

Almost all stories are completed the day of the review, causing problems including:

• Stories are accepted untested rather than production-ready
• Some stories are gold-plated or not quite on target
• Acceptance testing is cursory and does not include user testing

These issues were raised at both Sprint reviews. The main response was that many stories were linked so it was hard to deliver them separately.

How can I encourage or enable the developers to deliver stories throughout the sprint rather than all at the end?

Context: The team comprises three developers, two business analysts, and a Project Owner. The developers work at one campus; the rest of the team and all of the users work at another campus 15 miles away. The developers prefer to work in isolation: after a half-day kickoff, the groups have very limited contact until the sprint review. The developers are willing to use Scrum but resistant to a daily standup; the last sprint included one standup halfway through a two-week sprint.

Answer 1

I like the recommendations above. I would add a couple of things:

First, Start improving visibility during the sprint. The basic thing to look at is a Story Burnup. This focuses on the pace of closing stories, rather than work remaining. Its in my oppinion a much clearer visibility of the key aspect important to a team - Flow WITHIN the sprint.

Beyond that, consider adding visibility to the stories that are NOT done yet. They can be "TO DO", "In Progress", or maybe even "Dev In Progress", "Dev DONE", "Test In Progress". This visibility can be added to the team taskboard, and then to the burnup, by using Cumulative Flow Diagrams. I provide an explanation how to do it that people find useful over in http://www.slideshare.net/yyeret/explaining-cumulative-flow-diagrams-cfd

Once you have the visibility, what you want to do is:

• Drive towards smaller and smaller stories - these ENABLE reducing the batch size and pulling earlier into testing
• Limit the amounts of stories in progress - ruthlessly prioritize during the sprint - try to swarm to a few early stories and pull them all the way to Done, before continuing to the rest of the sprint backlog.

In essence, you are describing a waterfall within a sprint (aka ScrummerFall), while I'm trying to drive you towards a really Agile sprint... It is a classic behavior of starting scrum teams, so you are in good company! The tips I'm describing can help you get out of it.

You might run into other obstacles:

• stories cannot get any smaller (work on story slicing techniques - my friend Elad Amit is working on a cheat sheet to help with this... but for now look at What do i need to know to start being a product owner?
• we cannot swarm to fewer stories - each of us knows a certain area, or we cannot safely/effectively work together in the same area - now you really need to go Agile in your engineering practices! Continuous Integration, Collective Ownership, Pair Programming, and other practices help the teams ability to focus its energy on a smaller target...

Hope this helps!

Answer 2

There are multiple aspects to this. Firstly, your team has just started using scrum, so it needs time to get used to it. Introducing a taking advantage of what the different practices have to offer isn't always straightforward.

The sprint planning meeting should enable the team to break the stories down and understand the dependencies between these.

The team must adhere to a definition of done but also understand that the goal isn't merely to have it all done by the end of the sprint, but rather to reach a steady pace where (if estimations aren't too far off) the ideal burndown path is followed.

The daily stand-up meeting is one of the most important practices that scrum advocates and ihmo, it's what pushed people forward and enable peer pressure (ideally in a good way). Without the daily stand-ups, there's no update of the estimations, no awareness of the encountered issues, ... thus most of the benefits are lost.

Ask the team to try daily stand-ups for a few sprints and do the sprint retrospective meetings to try and improve the process along the way. Once people are used to it, they often agree that it helps them stay focused.

Answer 3

Based on the fact that all stories are getting "finished" on the last day, and are not tested properly, I'm guessing that you're actually taking on a few too many stories per Sprint. Try just a few less next time.

Also, if the team is blaming this on the stories being "linked", try to find ways to break those linkages so that more of your stories per Sprint are "independent". Maybe you can also break them down into smaller chunks.

The most concerning thing that you've mentioned though is the development team's unwillingness to hold a daily standup. This absence, coupled with the fact that they don't sit near the analysts and PO explains why you have gold plating and a disconnect on the completeness of your stories. Find out why (unless you know already) the developers do not want to sit with the rest of the team. Are there personality conflicts? Issues with the working space? Other? Whatever the reason, it's probably an issue or "block" that you as the ScrumMaster need to address. As the ScrumMaster, you are also responsible for how Scrum is implemented. You may need to insist, or at least strongly encourage at the next Retrospective, that the entire team hold a daily standup. If the developers aren't willing to drive the 15 miles to your other location, you can try holding it remotely via teleconference, but the fact that you're not having one is a huge problem for this project. Can you 4 (SM, PO, and business analysts) go to where the developers are for the daily standup? Just a thought. I don't know what the issues are, but if that's what it would take for the developers to be willing for the whole team to meet every day, it's something to consider.

Answer 4

I would suggest that -- because of the dependencies -- maybe a modified version of Scrum might be more applicable to your situation.

It pains me when I hear stories couldn't be completed because of dependencies and that there was too much work for the sprint.

Not to get too technical into the realm of software development and computer science, but one of the fundamentals of engineering is to break a problem down into smaller components and also create layers of abstraction.

For instance, if you're developing blogging software and one of your stories involves the user entering a post and clicking save to store the post in the database, and the ability to view a published post is dependent on the ability to save, your developers could use a placeholder to act as a "saved post" for the purpose of developing the retrieve post functionality.

Not only does this help facilitate loosely coupled systems, but the individual retrieve functionality can be tested independently of the full system as a whole. Once the actual real save functionality is implemented, then the entire system as a whole can be tested.

Of course, this isn't a project management problem, this is a development problem that could be solved if the developers can take a step back and think about the system more modularly. While stories are great for conceptualizing the features, the actual implementation should be more abstract.

Answer 5

The main response was that many stories were linked so it was hard to deliver them separately.

It sounds to me (and correct me if I am wrong) that the user stories were not defined by the developers. Stories that are independent rely on a deep understanding of the system, not just the end user experience. Maybe try having the developers come up with a set of independent user stories.

Also, I don't tend to have my user stories at 0 or 100% complete. Once completed by the developers, maybe mark them as 75% complete, so that the burndown will progress, but they are not done until tested.

Answer 6

My first sprint / scrum combo had a similar problem, due to a lack of realistic breaking down of tasks. The difference I had is that fully tested was a prerequisite of DONE.

Therefore I'd pick out a number of things:

1. Break down tasks in the smallest jobs worth measuring (jmort253's blog post scenario is a good example).

2. Break down the workflow into meaningful stages. I normally use To do | In dev | Test | Done as starting points, add and remove stages as necessary for you and the team to get visibility on progress. The team will start to see real progress. (Do you use any software to track task progress?)

3. I would try and get a routine scrum in some fashion or another, whether through a conference call or video chat. I can't tell you how useful it is. There may be resistance at first but if you can convince them that it's only ~10 minutes a day, you watch how quickly they start cross-communicating things they wouldn't usually think of telling other team members. It really is illuminating.