Theory Vs Reality
Scrum by definition is “A framework within which people can address complex adaptive problems while productively and creatively delivering products of the highest possible value.”
The fact of the matter is (similar to all frameworks) Scrum best practice is a guideline to follow, not a set of rules to abide by. There isn’t necessarily a right or a wrong answer in Scrum… except if you’re attempting to take the intermediate SCRUM qualification, then there definitely is a right and a wrong answer!
However, in terms of using the Scrum framework in your day to day role, as effectively as the text books and training materials say, all depends on various factors within your project and the resources available to you.
One of the main challenges we face on my Project is maintaining a healthy Product Backlog!
The Product backlog is the heart of your Development and needs to be regularly reviewed, nurtured and maintained to keep Development flowing at a good pace.
This can be a difficult task and here’s why…
In an ‘ideal world’ Projects have one focussed area of improvement, which means they have one Product Backlog, with all of their fully defined requirements ready, at the start of the Project.
These requirements are then written as ‘stories’, prioritised by the Product owner and placed in the Product Backlog.
The Development team will then pick these stories up, based on priority and place them into their Sprint backlog to work on, to meet the defined acceptance criteria (which is the basis of the agreed definition of ‘Done’).
The stories in the Product backlog will be re-prioritised, as necessary by the Product owner and the cycle will continue until the Project is complete…
Oh yeah and there is no dedicated Testing team to liaise with, as the Developers do all of their own testing, so there is no hold up on delivery!
That’s great… in an ‘ideal world’, where there are Resources at your fingertips, including Developers who make no mistakes, Systems that don’t encounter errors and a dedicated Product owner who sits down with all Stakeholders and regularly assesses the priority and detail of every single story in the backlog!
However, in reality your Client may not know, upfront what all of their requirements actually are. You also may not have the Resources and Stakeholders at your finger tips to baseline these requirements.
You may not have a dedicated Product Owner and in all honesty, you may not have the correct people writing your stories to begin with! Leaving you with various Requesters submitting vague and ambiguous requirements or placeholder requests that may never be touched again, resulting in an overall messy backlog.
This is what we started off with on our Project! And trust me you don’t want that.
If this is ringing any bells and sounds like something you have encountered or if you are worrying that at some point in the near future, this might be how your backlog will end up looking, then please, keep reading.
Below I have listed some Do’s and Don’t’s when it comes to maintaining a healthy Product Backlog and keeping some form of control over the requirements within it:
Do |
Don’t |
| Have one person accountable for managing the ‘front door’ for all requests | Allow everyone and anyone to submit a request directly into the product backlog |
| Have every requirement fully baselined and turned into well written stories, with a detailed description and acceptance criteria | Accept placeholders and vague requests with little or no description |
| Ensure all requirements/requests are signed off by the requestor before development commences | Start work on a requirement without clarifying that the requester still wants this work |
| Prioritise the stories based on client/ stakeholder expectations | Leave everything as medium priority and hope for the best |
| Estimate your stories in an agreed unit of time | Have several approaches to story pointing, which will result in confusion for everyone |
| Plan in advance- Answer the following questions: – What are your upcoming sprint timelines? (2,3,4 sprints ahead if possible) – What resources do you have available for these upcoming sprints? – What capacity can you fill each sprint to? – Are there any upcoming blockers or dependencies that may affect your sprints? – Which stories are of highest priority and have stakeholder expectations been met? |
Leave baselining requests until the last minute, rushing them into a sprint and setting unrealistic stakeholder expectations. |
| Remember Quality over Quantity- It is better to deliver less enhancements that meet a higher standard than to deliver more enhancements of very poor quality which may result in many defects and disruption |
Rush ‘half baked’ stories and solutions into the sprint- this could potentially result in wasting Developer time on something that will need to be re-developed later down the line. |
Now I’m not saying that the way our product backlog is created and maintained nowadays is perfect, we often rush around trying to plan and finalise the sprint at the last minute because requestors may not have approved their stories on time or there are some other dependencies holding the stories up.
What I do know is that we have certainly come a long way from where we began and we were not fortunate enough to come onto a Project that had a list of fully baselined requests ready in the backlog to be worked on in an upcoming sprint. We had a mess, to put it in simple terms.
What we now have is a tight grip on our Product backlog, we have one formal front door for requests and a dedicated resource to turn these requests into stories. We have a request pipeline that changes on a fortnightly basis and I am now confident that each requirement that is planned into every sprint has been fully baselined, has a high quality acceptance criteria and has been approved by both the Requester and Technical Architect. Timelines are discussed with requestors and we continuously deliver beneficial changes and enhancements to the business every month.
For more information email Rachael at rachael.ivey@methods.co.uk.