How SCRUM should work

Here’s an extract from an email I sent to my Scrum Master.

Now, I may be wrong on some points, so please feel free to comment and point out anything you feel I’ve missed or that I’m incorrect about.

Here’s my view on how scrum should work:

  1. P.O. creates stories – with story points allocated. Stories contain a field like ‘Is done when’ to place conditions on when the story can be closed (This is used for user-testing). Business-level. Stories should come from a release plan, and should have any requirements attached.
  2. S.M + team divide stories into tasks, with full descriptions on work to be completed. S.M. helps the team translate between business-level descriptions and developer-level descriptions of actual work needed to be done.
  3. S.M. + team discusses tasks, and estimates amount of hours for each task. Team also reports (in the ticket) expected new automated tests which will be written after the work on the ticket is completed.
  4. P.O. + S.M. + team select and agree on a number of stories and commit to finishing them during the sprint. Sprint backlog is born.
  5. During the sprint, requirements can be introduced or changed, which alter the scope of the tasks. This is an Agile fundamental, and cannot be prevented. The change of scope can arise when the developer looks more deeply at the task, or when external requirements change. It’s not a cause for panic!
  6. During the daily stand-up meeting, developers have the chance to explain the change in scope to the team, who agree that the task can be completed, or agree that it cannot, and offer their assistance if needed (a team is a team, not just a bunch of individuals).
  7. If the new scope is too much to handle, the story is either stopped, the original requirements are completed, or the story is moved out of the sprint and something is moved in (the P.O. makes this decision).

Things to remember:

  • There’s one person who is going to be killed for problems with product delivery. Me.
  • The Scrum Master is responsible for making sure the sprint backlog gets completed.
  • The Product Owner is responsible for making sure the completed work gets delivered.
  • There’s no such thing as a failed sprint. (I got a surprisingly negative reply in a scrum discussion when I talked about ‘failed’ sprints.)
  • The Product Owner always has the power to meddle with the sprint and the product backlogs. The Scrum Master and team do not.
  • The Product Owner and the Scrum Master are part of the team. They are just roles.

During the sprint:

  • The Product Owner is gathering requirements for the next batch of stories in the product backlog.
  • The Product Owner is communicating with stakeholders, and users, and getting feedback on the release plan.
  • The Scrum Master is massaging the team, developing, and keeping the sprint on schedule.
  • The Scrum Master is reporting problems and difficulties to the Product Owner.
  • The Team is taking tickets, developing them, and writing automated tests.
  • The Testers (also part of the team)

The reason I’ve sent this email is because I felt we’re not implementing Scrum correctly, and need to make some changes. Of course every company will mould scrum somewhat to fit their world, but I still think that from time to time, it’s quite useful to step back and re-evaluate. Particularly in the first year during which this process is implemented.

Leave a Reply

 

 

 

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Anti-Spam Protection by WP-SpamFree