This is not only the 1st step. It’s the most important step.
Align with Business
Firstly, before you do anything else, you must align your development team with the business.
If you’re part of a business unit, that might be natural and straightforward. If you’re a central development organisation serving multiple business units, developing multiple products, it might be harder. Initially, make sure you have at least 1 person dedicated to a product, application or product range where you will start implementing Scrum.
You can share a team split across multiple products. But it’s a little harder and therefore is a slightly more advanced technique. If possible, it would be ideal to avoid this situation in your first implementation of Scrum, if you can.
Start with BAU
Secondly, although you can use Scrum on projects to good effect, you should start with BAU (business-as-usual) rather than on big projects. This will keep things simple while you and the team get used to the basics.
So you’ve decided on a product where you will start using Scrum. You have at least 1 person who will be dedicated to that product (or product range). To keep things simple at first, you have selected a product that is in the BAU cycle of bug fixing and enhancements.
Find a Willing Product Owner
The next key step is to nominate a Product Owner. You must find 1 Product Owner. 1 person who will be responsible for prioritising work on the product. 1 person who knows what is required of the product. 1 person that is a good communicator and able to convey requirements. 1 person who is committed to the success of the product, such that they are willing and able to dedicated a reasonable amount of time to its development.
If, for whatever reasons, this step is a problem for you, DO NOT PASS GO.
If you can’t complete this step, your product development is likely to be fraught with issues. Whether or not you implement Scrum. Unless you can take the above steps, it’s quite possible you will be faced with a barrage of requests, no clear view of priorities, a lack of clarity about requirements, lots of noise and complaints, and being pulled from pillar to post. The consequences? You don’t deliver and/or fail to meet expectations. Everyone is miserable. And somehow it’s all your fault! Unfortunately, this is all too common a situation for development teams everywhere. This must be solved before you proceed. This is a critical success factor for your team.
Act as ScrumMaster
So now you are organised. You’re aligned. You have 1 product, application or product range. You have at least 1 person dedicated to the product (Scrum Team). You have 1 Product Owner. And you, by virtue of the fact that you’re reading this information about implementing Scrum, I will assume are probably the ScrumMaster.
As ScrumMaster, you are responsible for supporting the Scrum Team, coaching and guiding them through this process, and removing any impediments blocking their progress.
Create the Product Backlog
Now you must create the Product Backlog.
The Product Backlog, in its simplest form, is a list of things that people want to be done to the product, in priority order.
Anyone can add anything to the Product Backlog. Anyone. The Scrum process, and agile development principles generally, are collaborative and inclusive. There is no longer any need to say no.
Only the Product Owner can prioritise the Product Backlog.
The Product Backlog can contain anything relating to the product that is : bugs. Enhancements, whole projects, issues, risks…
Having said that, items on the Product Backlog should ideally be expressed in business terms that are of some value to the user (or customer, or business).
Functional requirements should be expressed as features. Non-functional requirements can be put on the Backlog too, for instance ‘the product needs to be faster’, ‘we need to ensure the product is secure’, ‘we need to get off the old platform’, ‘there’s a high risk of downtime due to a single point of failure’. These might not be features, as such, but they are completely justified as items on the Product Backlog.
Prioritise the Backlog
The Product Owner prioritises the Product Backlog. He doens’t categorise the priorities 1, 2, 3 or anything like that. The priority is determined simply by the order of the list. The Product Owner puts the Product Backlog in priority order.
Things at the bottom of the list may be way off and may or may not ever get done. Things down the bottom are likely to be fuzzy and ill-defined. Don’t waste time defining things you may never get to, or not get to for some time. If something is a bad idea, the Product Owner should explain to whoever requested it why they are removing it from the Backlog. However, if something’s not such a bad idea, although never likely to be done, just put it in its rightfully low place on the Backlog and explain to the requester where it fits with priorities.
Extract from Kelly Water’s blog