Succeeding with Agile

Mike Cohn

Mentioned 5

Provides recommendations and case studies to help with the implementation of Scrum.

More on

Mentioned in questions and answers.

How to move a team from waterfall development model to scrum model ? What all are the steps that one need to follow to achieve a smooth transition. What would be the acceptance curve and will it be successful altogether ?

First the team needs to want the change, and the business has to support it.

There isn't a set sequence of steps, and success can vary widely, as much depends on your particular situation.

I'd recommend getting Mike Cohn's book Succeeding with Agile, which gives some excellent advice for such a transition.

During the past year, our organisation has began using Scrum. Over the past few Sprints it has become apparent that our Scrum isn't really working - we have difficulties with dependencies of certain tasks, and we are way off on our burn down charts.

Historically, we'd never paid any attention to our velocity and complexity of products, and everything was pretty much a guess.

We are nearing the end of our first Sprint on our new project. I have been working over the past couple of days of ensuring that we have a prioritized, complexity estimated product backlog. I retrospectively added the user stories that we are working on in the first sprint. It's quite apparent that we have bitten off more than we can chew.

We estimated our team velocity to be 28 story points, however, we haven't actually finished any of the user stories. Is our team velocity actually zero, and if so, how do I begin trying to plan the next sprint? Do we need to re-estimate our team velocity going into Sprint 2? Or can we take a best guess of what our velocity actually is given the percentage of the user stories we've actually completed?

Another issue we have is that our team is split into three tiers - Data, UI, and Services. This can make Sprints difficult to plan because of the different skill sets. For example, we have a very large user story which involved importing data from our legacy system (almost a whole sprints worth), but only our Data guys are able to work on this story, so we need to add additional stories which will allow the UI and Services team to also be involved in the sprint. We are then stretching ourselves even further.

Not many people on the team understand Scrum that well. I did a Scrum master course about 4 years ago, and I've forgotten a lot of what I'd learned, and I'm really struggling to get this Scrum team working well.

We have a scrum team of 14. Is this too big, should we try and have two smaller scrum teams? We are all working on the same project.

I'd be very appreciative of some advice from seasoned Scrum Masters on what we can do to try and help our Scrum process.

It sounds like the retrospective for this sprint will be interesting! These are some of the things that I might try and encourage the team to focus on in the retrospective:

  1. Your velocity is unfortunately 0 because no stories are Done. I would encourage the team to consider:
    • What went wrong with the unfinished stories? What stopped them getting to Done?
    • Were the stories too large or complex? If so, how could they have been broken down? Beware splitting the stories into "layers" - stories should be split into vertical slices so each story still delivers an increment of user value.
    • Did the team start too much and not focus on finishing what had already been started (too much work in progress)?
    • You might need to remind them that the team as a whole succeeds or fails - if one part of the team struggled it was up to the rest of the team to support them and come up with a solution.
  2. As discussed above, stories should be vertical slices of functionality, not horizontal ones. This is tricky because software engineers often think in "layers". How can you overcome this with the "tiered" team? In particular, how can you avoid hand-offs between the three groups (hand-offs are expensive and cause delays). Some thoughts:
    • Could the Data team have provided a stub (e.g. an interface that returns hard-coded dummy data) to allow the UI and Services teams to proceed while the data layer is being completed?
    • Could a cross-functional group have swarmed on each story (so all three "tiers" are forced to work together on completion of a story)?
    • How can the tiers cross-train so they can take on work outside their specialist areas (this is the concept of "generalising specialists" or "specialising generalists"). This will allow them to support each other when the going gets sticky.
  3. Is the scrum team too large (probably)?
    • A "two pizza" team of 5-9 members is ideal
    • Would it be possible to split the team into two scrums with people from all three tiers in each scrum?
    • Each scrum can work independently on an epic

Outside the retrospective, the scrum master and product owner might want to think about a couple of things:

  • Backlog management is really important (and really hard to get right) - it sounds like you have done lots of work on this, but it is vital to keep it up. A poorly groomed backlog will stall the team.
  • If you have silos (e.g. between the "tiers"), you need to work to break them down. Silos reduce the team's flexibility and create hand-offs which are expensive.

Finally, "Succeeding with Agile" by Mike Cohn is a really great book which covers the practical side of making scrum work in the real world. I found it extremely useful.

Given that the tasks in a specific sprint will not divide perfectly into the team, and all finish on the same date, what do you do to keep everyone working as the sprint moves into its final stages?

Inevitably it seems like there will be one or two people freed-up. If all the other tasks are done-done, and the remaining tasks are already underway, then what?

Do those team-members pick up items from the top of the product backlog, as they are likely to be needed in the next sprint anyways to get a head start?

What do you or your teams do?

While it may seem obvious for team members to move on to the next highest items in the product backlog, I would advise against starting with this.

First and foremost, the teams' obligation is to achieving the sprint goal, so anything they can do to work towards that must come first (e.g. helping out testing, chipping in where possible, etc.).

Next, the team should look at expanding their definition of "done". Perhaps it currently doesn't include testing, or doesn't include some form of code review. Most teams starting with Scrum do not start with a definition of done that truly has a product increment that is ready to ship, so now would be the team to move towards that.

As others have mentioned, what tools do you need setup in order to get closer to a shippable state? Continuous integration? Automated acceptance tests? Now is the time to add these things.

Likely, you also have areas of the code that existed before you moved to Scrum and thus don't have very good test coverage or have accumulated technical debt. Now's the time to pay that off.

Also, as Mike Cohn suggests in his book Succeeding with Agile teams may want to reserve roughly 10% of their time for some look ahead planning. This may involve having a meeting with the Product Owner to discuss some up and coming stories for future sprints, breaking down larger stories into smaller ones, or for designers, perhaps doing some wire frames or mock-ups for upcoming stories.

Once you've gotten to this state, only then should you consider continuing on with the product backlog.

When using an agile methodology on a team programming project, what should be done when several people needs to work in something that is to be used by everyone. For example, There is a User entity, and two people have to do requirements that need to use that entity. So, first an skeleton is created and then the activities are assigned? or what is the procedure in these cases.

And second, Is it possible to find information that addresses this kind of issues that can occur when applying such methodologies?


The best thing about Scrum, is that it is an amazing tool for identifying bad practices. This is one of the cases. An agile team should be working with as many hands as possible, on the same requirement (requirement, feature, user story - same thing). The division of work between members should be based on the tasks needed to complete the requirement, no the requirements themselves.

Each task would be defined based on the modifications that need to be made to a certain component. Doing that will not only make the problem go away (nobody's working on the same code), but will unite the team members' efforts, and make them function as a real team, rather than a disparate group of individuals that happen to share a room and a manager.

As for official information on the subject, I can suggest reading any book about Scrum, but you might want to focus on the following sites:

A few great books:

And finally, if you pardon the shameless plug, you can check out my blog - I have a few posts on this subject (such as this one) and others from my experience about implementing agile methods in software teams.

Where can I find a practical example on how to use Bug, Risk, Scenario, Task and Quality of Service Requirement work items?

On MSDN documentation I found this topic: but it is not enough for me to deeply understand when to use one or the other.


I don't think there is a single prescriptive way of using the work items. You have to adjust this to your own process and your own needs and primarily decide what you want to get out of TFS a this particular process template.

A good place to start might be the literature on agile methodology, for example: