Some tips for a successful scrum project

If you want your scrum project to succeed, I've learned a few tricks that work for me in ten years of running Agile projects. Here are some of them:

• Education, education, education
• Keep stories tiny
• Keep sprint cadence to 2 weeks
• Reserve one sprint in five for tech debt
• Set up the rules early
• Update the estimates with the actuals
• Make stand-ups useful

Education, education, education

Everyone on the project / product development should know what you're doing and how you're going about it before you start. Spend time working out the best way to achieve that, depending on your circumstances.

Be aware that a number of your team and several of your stakeholders will think they already know it all (and not really listen) or be unavailable for any sessions you plan. That's a fact of life.

Plan what you want to cover. Plan multiple sessions. Seek feedback. Implement the feedback.

After you think they've got it, have a refresher session a few weeks later to hammer the message home again. Some people will have misunderstood some of the original points.

Keep stories tiny

A team member (or pair, if you're pair programming) must be able to complete a story within a sprint. I suggest that in general practice they should be able to complete several stories in a sprint.

Whether you estimate in days or story points, make sure the stories are prepped so that none of them are expected to take more than 25% of your elapsed sprint time. That will minimise the risk that stories spill over into subsequent sprints.

Using that rule of thumb quickly reveals the level of granularity that a story should attain prior to the sprint commencing. If you aren't sure whether it's small enough, it's too large - break it down.

No one ever complained that too many stories were being done in a single sprint, though they might complain that the stories are too small to be useful. If that's the case, consider increasing the size and combining dependent stories, but not beyond the 25% limit.

Keep sprint cadence to 2 weeks

I like to start off any development with a set-up sprint, which is often referred to as "Sprint Zero". Sprint Zero may be longer or shorter, depending on your circumstances, but make sure that everything required to start sprint 1 is ready before it ends.

If you're running a scrum development, keep sprint cadence to 2 weeks after Sprint Zero.

Having longer sprints might make you feel as though you’re getting more done, but it delays the feedback loop. Too long and you're doing mini-waterfall.

Conversely, if you're following scrum, shorter sprints are too overhead-heavy and the ceremonies will get in the way of available development time.

If you're working on a Kanban principle instead, I'd suggest having a backlog and progress review every couple of weeks anyway. Under busienss pressure, it's easy to forget that a large part of Agile is to try, fail fast and learn from it. I've seen teams that don't achieve those objectives due to rushing ahead without taking any time to review their approach or to communicate and learn from each other.

Reserve one sprint in five for tech debt

Tech debt accumulates. Like any debt it gains interest and becomes worse the longer you leave it. Plan in times when it will have your focus as you proceed. That sets expectations amongst stakeholders and improves quality without stifling initial creativity and the right to fail. Going back to my education point, it is vital that this approach is clearly understood by all parties from the outset.
Having a tech debt sprint every quarter or less empowers your team to not be afraid to not achieve the perfect solution - they know there's a built-in safety blanket and they'll perform better and work more efficiently.

Make sure that you plan what tech debt will be covered in the sprint and size it as you would any user story. The work will expand to fill the time available and some problems will be very tricky to fix. If you aren't going to complete a challenge within the sprint, consider setting up a new team to continue to work on it, or just park it for the next tech debt sprint.

One final word of caution: keep an eye on your developers. Rabbit holes are fun, stimulating challenges but they need to be ready to work on the user stories in the following sprint.

Set up the rules early

Ideally during the discovery phase, but by the end of Sprint Zero at the latest, establish a set of golden rules that cover the working principles that will be adopted throughout the project. These should include:

• Ceremonies (identify which ones there will be; how often; who must attend; what to do if they can't attend)
• How to treat your colleagues (e.g. turn up to meetings; let everyone speak; listen)
• Architectural principles (e.g. technology stack; service definition; encapsulation; reusability; security; versioning; scalability; performance targets)
• Tools and tool use (what; when; minimum content; standards ; tool integration / overlaps)
• UX principles (e.g. pattern libraries; personas; reskinability; accessibility)
• What makes a good story (e.g. size; depth; BDD scope; atomicity)
• What the difference is between a user story and a task (e.g. how to break down stories; technical tasks as stories; how they link together)
• DevOps principles (e.g. continuous integration; continuous deployment vs build frequency; infrastructure as code; )

Make sure that everyone on the development team has buy in to the rules. Review and revise them after a few sprints.

Update the estimates with the actuals

How many times have you spent a lot of effort estimating stories only to never look at the estimates again once the stories have been built? As part of the retrospective for each sprint, look at the estimates for the stories you completed and revise the numbers based on the actual time or story points spent on implementing the story.

That way, when a similar story appears much later in the development, you can refer back to the story just completed and gain confidence in knowing that your new estimate is based on reality not new guesswork.

In addition, record any unforeseen issues you had with it and how you overcame them. Remember, it might be a different developer or team working on the new story and even if they'd like to estimate for themselves, they'll benefit from your experience and insight.

Make stand-ups useful

"Every day we waste an hour in stand-ups" is a common complaint amongst developers. If you follow the rigorous "what I did yesterday / what I'm doing today / what are my blockers" paradigm, they can be slow and tedious, to the point where they become something people try to avoid.

To combat the attrition:

• Make them actual stand ups, not "sit downs"
• Start on time
• If your team is scattered geographically, use video and make sure it works before the meeting starts
• Impose a 2 minute limit per person and impose 30 minute limit in total
• Instead of making them a progress report to the scrum master, try only speaking about blockers and other immediate issues
• Don't fall into the trap of trying to solve a problem in the meeting - you'll be wasting the time of everyone who isn't interested - arrange a post-stand-up conversation instead
• Don't feel the need to speak if you have nothing to say - just say that there are no changes

What's your experience?

Hopefully at least some of that has been helpful and I know you'll recognise many of the issues identified. If you have any other tips, please feel free to comment below.