Scrum/How-to for teams

This page provides a basic guide to Scrum for those in the role of the team.

Advantages of Scrum

As a team, Scrum gives you more freedom to guide your work. It is now up to the team members to raise concerns they have, address problems that arise and determine the right pace of work. If you take it seriously, Scrum eliminates the need to deal with ever-changing work requirements that are improperly defined and lead to panic and rush. It also means you will be working closer with each other, learn more and extend your competence.

By allowing you to exercise control over your work, planning your time and achieving your results, Scrum should result in a better work experience.

Disadvantages of Scrum

Scrum require that you take responsibility - for your work results but also for the readiness of work you begin. It means you are not just doing what you're being told, but that you have to critically question everything that your Product owner points your way. Is it defined clearly? Is it broken down into small chunks of value that we can easily deliver? Are we positive we can do it? Only if you can say yes you should accept work.

Scrum means being able to say no and standing up for it. If unstructured requests come in, work requests are not sufficiently defined or problems are not being solved you need to stand up and insist. Your vigilance is what keeps the process healthy.

Done is done

In Scrum only done is done. Work has to be complete, tested and documented. Less than that is not acceptable.

Look at all your tasks from the customer perspective. Does the work have everything you would expect? Is it properly documented? Is it tested and working well? Are all the deliverables available? If you think your product owner or your team mates have forgotten something, bring it up for discussion!

Ensuring built-in quality

Make sure your work is not just done, but done well. Is the architecture solid? Will your changes survive the next updates? Have you talked to those who will be affected by your changes? Is the solution simple enough to be tested well? Can you break it into smaller pieces that make things easier?

Make sure to use automated tests wherever possible and think about the test cases early when developing something. Get help from your team's QA contact if you have doubts about how to ensure best coverage. Their experience can help you be better. If you run out of time with your work, flag it as soon as possible. Never try to keep a deadline by trimming back your work quality. Yes, it will probably work in the short term, but eventually it will come back and mess up your planning and your reputation.

What if you find problematic code areas that should be improved or refactored? Talk to your Product owner and get the cleanup onto the Product backlog right now.

What if you have found bad code that is blocking a task you have in your current sprint? Discuss the issue in the team and escalate this to your Product owner immediately. The work should be deferred and a higher-priority task to fix the problems needs to be introduced. This will usually result in replanning your sprint.

Your role in a Review meeting

In the review meeting your job is to give the Product owner maximum clarity about what has been delivered. Try not to go rambling as we have a Timebox to keep, but outline clearly what has been done. Explain it as you would briefly explain it to someone who was not present in the planning meeting and doesn't know what this is all about.

Whenever possible, have a brief demonstration of the functionality prepared and show it to the Product owner.

Please also look at the Retrospective items you have taken with you from the previous sprint(s). Did you adhere to these reminders in your work?

Your role in a sprint planning meeting

In part 1 of the meeting, the Product owner first presents the product backlog to you. Make sure that each of the stories is crystal clear and ask your questions. Do not assume that someone else understands things better than you (unless they really do and can explain it to you so you understand it as well).

If you know that something need to be done and it's not on the Product backlog, or not with a sufficient priority, raise it!

If a story requires some other work to be done as a prerequisite, make sure it's on the product backlog and prioritized higher than the story.

Now you need to estimate the stories in Story points. Use previous tasks as an orientation for choosing the right number of points. Keep the estimates quick, it should really just be a thumb in the wind. Be as conservative as your previous experience has taught you to be! If items turn out to be very big (so they cannot safely fit into one sprint) it must be broken down.

After this you need to commit what stories you can take into your sprint. Start from the top of the product backlog and step by step accept stories into the sprint until it is full. Only accept items if they are ready to act and you are really comfortable committing yourself to their delivery. If something large contains risks it should also be broken down so that the lower-risk value can be delivered first.

Have a look at the historical performance of your team. How many points did you get done in the last sprint? How many are you planning this time? And if those numbers differ, why?

The product owner leaves the room and Part 2 begins. Now you have to detail out the tasks and fill the sprint plan.

Discuss together what the individual steps will be in order to achieve each of the stories you have accepted. Make sure to remember building in quality and making sure that done is done. Do you really have everything that makes this deliverable complete? If your team plans with hours, estimate each of the sub steps now.

If you discover that the committed sprint stories result in a sprint plan that uses more hours than you actually have, identify how many items would need to be dropped out from the bottom of the sprint to make it feasible and call in your product owner to discuss this with him.

It is tempting to reestimate tasks in order to reduce their estimated hours ("ah, 12 hours instead of 16 will be fine for this"). Don't.

Your role in a daily scrum meeting

Tell your team members what you were doing since yesterday's Daily scrum. What are you planning to do today? What problems did you hit or are going to slow you down today? Do you need help?

Make sure any problems that come up are addressed. This may be as simple as asking someone for help. But it can also mean you have to involve your ScrumMaster and push for major changes in the company.

If you see that any task in the sprint comes under risk because of these or because you're running late, flag it right now!