Understanding Scrum
04 May 2013
In software product development, the lack of organisational culture can lead to deliverability failure even when a project plan is in place. Organisational processes are essential in project planning as they enable a stable process performance in any organisation. They also provide a basis for an increasing set of standard processes that highlights the often neglected issues in a software development environment.
One of the Agile Development methodologies (Scrum) is being introduced into the product development process at my company. What prompted the introduction of scrum is the direct and continuous interaction of stakeholders with the team in charge of product(s) development.
So what's Scrum?
Scrum is an iterative, agile development methodology for creating products shippable features by using a time box called Sprint. The Scrum Team consists of:
- Product Owner: sets priorities and signs off development
- Scrum Master: manages the process and removes blockages
- The Team (Technical and Nontechnical): Develop the product
- Stakeholders: observe, advise, and raise ideas to the Product Owner
Before the sprint, the Product Owner creates and maintains the Product Backlog. Product Backlog (user stories) are list of requirements and issues owned by the Product Owner. It can be contributed to by all the parties involved but can only be prioritised by the Product Owner.
On the first day of the sprint the Product Owner, Scrum Master and the team hold Sprint Planning:
- Product Owner presents items
- Team estimates items
- Team selects items based on priority
- Team creates Sprint Backlog (List of items selected by the Sprint Team. It is a commitment of what will be completed during Sprint and it is owned by the Team)
In addition, a realistic planning of the deliverable helps breakdown the process and create a Sprint Backlog. There is a useful app by Unboxed Consulting Limited called Poker Planning. Poker Planning uses Fibonacci sequence for story sizing as it reflect the existing doubt in the approximate estimation of quantity of bigger items.
On everyday of the Sprint, a daily Stand Up (Scrum) is held and attended by the Team and the Scrum Master. Product Owner and Stakeholders may choose to observe but not participate. Speakers (The Team) take turns to:
- Describe the activities of the previous day
- Explain the plan for the present day
- Highlight anything that is in their way to complete the work
During the Stand Up, the Scrum Master uses the session to manage Blockages (impediments and blockages that stop one or all items from being developed and are updated daily).
At the end of the Sprint, A Sprint Review and Sprint Retrospective are held. These sessions are used for:
- The Team to present the work to the Product Owner and Stakeholders (Review)
- The Product Owner to review and accept/reject the work (Review)
- The Team to discuss any issues that arose in the Sprint (Retrospective)
- The Team come up with solutions to any issues to implement in future Sprints (Retrospective)
The above is a sketchy summary of my week long scrum training which continues next week. I picked up a book (Essential Scrum: A Practical Guide to the Most Popular Agile Process) at Waterstones on the subject yesterday. Hopefully, I will get some reading done this weekend as it is bank holiday weekend.
A big thank you to Marijke Langenhoven for taking time out of her busy schedule to educate my colleagues and I about Scrum.
Learn and adapt. Ciao!
First week update:Performance-wise, we executed and completed all the planned stories in the sprint mostly because we committed to granular tasks and over-estimated nearly everything (rookie mistakes). Also, unallocated “bug fixing time” during last week’s sprint could have resulted in deterministic chaos supposing we had much demanding tasks to complete. According to the Product Owner, the best effort strategy is to allocate “bug fixing time” and fix as much bugs as we can during the allocated time.
Team's first week Sprint Burndown chart.












