As anyone with experience of Agile Scrum knows, there’s no one size fits all solution to applying it to your project.  As a Scrum master with nearing a year’s worth of practical experience, here I aim to describe how we are using Agile SCRUM to develop applications within our business.

But what is Agile Scrum?

Plenty of better informed people than me have explained this all over the internet (particularly at https://www.Scrumalliance.org/), but essentially it is a

“set of principles and practices that help teams deliver products in short cycles, enabling fast feedback, continual improvement, and rapid adaptation to change.”

Why are we using it?

We have been tasked with developing a dashboard showing 8 key business metrics by aggregating data across multiple existing business applications, and presenting this to managers in an easy to digest format.

To a certain extent we are using Agile Scrum as certainly at the beginning we didn’t know what we didn’t know, and rather than spend weeks designing an application, it was easier to jump in to a single part of the task, and get near instant feedback from our customer, enabling us to make more informed judgments about later aspects of the design and implementation of the application.

How are we using Agile Scrum?

I like this picture from agileforall.com

It shows clearly how the Product Owner is responsible for collecting the needs of the business, in creating a list of Stories in a Backlog, which we refer to as the Story Book.

Fortnightly, we hold a Sprint Retrospective and Planning meeting.  In this we analyse what went well, what didn’t go so well (and how we could do it differently next time), and if we have implemented the changes we identified at the start of the Sprint.  After this we determine our availability in hours for the next sprint.  This is the fed in to task planning, where we note the incomplete tasks from the previous Sprint, work out if they are still valid, and if the estimate in hours to complete them have changed.  Usually this will leave us with plenty of hours still to fill, so we go to the Story Book, take the next task that can be progressed (as prioritised by the Product Owner), and estimate all the tasks needed to complete the story.  We may consider it not possible to complete all of these tasks in the next Sprint, so will exclude them from our calculations.

Then armed with our Task List, we create post its that are pinned to a board, assigned against the appropriate Story (I have covered the Scrum Board in a separate post).  We have daily stand up meetings where everyone involved attends, and I as Scrum Master invite everyone to report on their progress.

  • What did you do yesterday?
  • What will you do today?
  • Do you have any impediments?

Each completed task has the number of Actual Hours recorded against it. Each task moved to In Work has at least one name assigned to it.

After the meeting I then collect the completed tasks, and record these on our burndown charts, which are then pinned to the board so the whole team can see how we are progressing.

At the end of each Sprint we get back together with the Product Owner to demonstrate the progress made in the Sprint, to collect their comments that can be used to generate Stories and Tasks for the next Sprint, and to give them confidence that things are progressing satisfactorily.

Customisations to Agile SCRUM

  • We found the following approaches have helped with our use of Agile SCRUM
  • We don’t use story points to estimate the size of Stories.  We found this too unreliable, so instead just do a task breakdown.
  • We usually increase the number of tasks in a Sprint, due to unexpected rework that needs to be completed urgently.  While tasks are raised for this, it’s not considered a problem, we just also mark on our burndown charts to over-committed hours.
  • We have a single never-ending task called “Overheads” for collecting meetings, and other miscellaneous activities that don’t fit under another sort of Story.

(There are probably more, and I shall add them as I think of them)

Conclusion

As mentioned at the top of the Post there is no single approach to Scrum, and it needs to work for you and your team.  Don’t be afraid to take the best bits, and leave what’s not working for you behind.  No one will know but your team, and they won’t care!

Hopefully you found this useful, and if you have any comments please leave them below