I know there are lots of talks and articles on agile and scrum. But I would like to know how to improve your scrum sprint for a new and small team. We are looking for a sprint length of 3 weeks. I would like to see some real experiences explained rather than the text book points.

  • Abdel, good question, I just need a little of clarification. On your question you said improving your scrum sprint, but the description sounds like this is a new team taking Scrum for the first time. Do you have any pain points right now? Having a small new team in itself is challenging, just wondering if I am reading the question correctly, before I answer.
    – Geo
    Feb 14 '11 at 20:49
  • Yes, we are a new team with our first scrum running (will finish next).. I feel we are slow, going off track! But i think its ok for the first few times.. so I put of this question Feb 15 '11 at 5:13

A few ideas which may work:

  • If you have fairly inexperienced team but at least one of team members has some experience in different work environments let her share her ideas what may work and try to adopt a few of them (not too many).

  • If the team is fairly new to Scrum make sure everyone knows you treat first sprint/first couple of sprints as experiment - the most valuable thing is how much everyone would learn, not how much work would be done.

  • You may break regular routine of doing retrospectives at the end of the sprint and do retros more often. If team members generally trust each other you may try to make ad-hoc retrospectives.

  • Find someone within the organization who is experienced with Scrum. Ask him for help. Let him do some mentoring or at least share his knowledge. Treat him more as an adviser than a decision-maker. In other words if the team doesn't want to follow a specific idea/technique don't enforce it on them.

  • Change your sprints gradually. After each sprint find just one or two things which are most painful and don't change more. This way you'll learn which changes work and which don't. Also you won't overload people with too many new things which should support adoption success.

  • Make decisions with the team. Let them decide what you try and what you don't try. Don't enforce new techniques or practices on them. Try to be more of a coach who's asking right questions to help the other side find the right way by themselves instead of serving well-done solution for every issue.


Scrum has a concept of a "sprint retrospective," where you sit down as a team and talk about the good and bad that came out of the last sprint. Use it.

To use it effectively, I recommend asking each team member for their top three positives (good things we want to do again) and negatives (things that went wrong that we want to fix next time). Tally everybody's votes together, and take the top three with the most votes. (You'll see repeat themes pretty frequently.)

Then implement your team suggestions, and move forward.


One point not covered above is sprint length. With newer teams I've generally found that shorter iterations work well with a small and newly minted scrum team ( 1-2 weeks ).

With longer sprints, I find that;

  • team members tend to "forget" about roadblocks encountered during the sprint and those items are lost within the sprint retrospective
  • planning / estimation meetings can eat up a lot of time when kicking off a new sprint
  • if you have a bad sprint your laundry list of things to try can be quite extensive
  • depending on the project & your customers, you may have "injection" fever where items are brought into a sprint because the customer simply can't wait until the next sprint.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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