Thinking about adopting SCRUM?
Purpose of this article is to share my experience and some tips that worked for the team I built and led. For folks and enterprises trying to transition to Agile way of working, there are so many things they can do. However, without doubt scrum is at the heart of it. It doesn’t matter what flavour of Agile you follow or try to follow. When we talk about Scrum, there are 5 events you should follow. In addition to the events, you also need team contracts (well not a literal contract), where as a team there is a ‘Definition of Ready’ and ‘Definition of Done’. I will unpack them one at a time and will do that in a sequence.
As a sidebar, I am making an assumption that if you are reading this, you have a fair idea of team backlog (aka sprint backlog) - It will have a list of stories that the Agile team works on.
Let me expand on these and start with key definitions -
Definition of Ready (DoR) – It simply means that the story is ready for a team member to work on. It has enough details and acceptance criteria that will keep the team member going. This is very important and should ideally be captured in Confluence or a white board or whatever your team is using.
Definition of Done (DoD) – Another key definition that as a team you should have an agreement on, this is where the card/user story has met all the Acceptance criteria and has been accepted by the PO (Product Owner).
As a team, if you haven’t established these two definitions then I would suggest go ahead and get an agreement on these otherwise each story can(and will) be stretched and interpreted differently. Now as a team, we have contracts ready, let’s talk about events. As I touched on before, there are 5 such events and each play a very important role. Hence, I would suggest not to make any of them optional. Let me start with the one that’s mostly ignored.
Backlog refinement – Purpose of this event is to ensure the team understands what’s coming in the next sprint. This is mid-sprint event and that has worked perfectly well for the teams I was leading. When I ran my first sprint, I kept this at 2 hours as it was greenfield product and the team was still being formed. Within few sprints, my team was beautifully formed, and 90 mins worked really well. Ideally you want everyone in your team to attend this so that there are no surprises at the sprint planning. However, I would suggest use your judgement, try few things and figure out what’s working well.
2. Sprint Planning – Most of the teams follow this, although I did hear few instances of this being ad-hoc. Anyway, if you are running sprints, you have to plan for it. This is where your DoR will come handy, by the time you leave your sprint planning event, stories should be committed and pulled into the sprint. Now, on this event what worked really well for me, setting some key goals at the start of the sprint - it took me 2 sprints to realise that though and maybe that’s the realization I am having in the picture. It keeps the discussion focused on what goals we are trying to achieve in this sprint and which stories link to that goal. When I didn’t have these goals, discussion was going all over the place. As a team, at the end we refined original goals. Another key item to keep in mind is breaking your velocity/capacity into different buckets. I used 70/20/10- 70% for new functional stories, 20% for enabler stories and 10% for bug fixes/spikes
3. Daily-Stand Ups (DSU) – From what I know, most of the places where they start using Agile, this is the first event that gets applied. By definition, it’s pretty simple – what did I do yesterday, what am I going to do today to meet the sprint goals and any impediments. My rule of thumb is 1 minute per person and if anyone needs more than that, ask him/er to stay for the ‘meet after’.
4. Sprint review and Demo – This is another event that I have seen most of the places adopting really fast, key is to review your sprint goals as a team and demo the working product to your customers (and most importantly know your customers – it’s easier said than done). This is a great opportunity for customers to provide feedback, I have seen more engagement from end users when we went remote. They were all commenting when the demo was being done and people were liking the comments. At the end, the team should collect all the feedback items (good and not so good) and address them in the coming sprints. Another key aspect to demo is how long should you spend to prepare. It’s test and learn, however in my program of work, I asked the person demoing to timebox it to 1 hour. From experience, putting boundaries and structure around this has worked really well. As for the demo itself, again 1 hour has worked well and if you are starting fresh, you should give that a go too.
5. Sprint retrospectives – This is a key event for the team – and should never be made optional. In terms of duration, 1hr is a good trade-off, however if you have big team, you might think of stretching it to 90 mins. Here is a popular guideline and from experience I am seen this to be very effective - Keep doing, Stop doing and Start doing. It’s also a safe place for the whole team (without the customer or the management) to share their thoughts and have a healthy debate. This is also a place where you might notice some healthy conflicts, if you are the scrum master, it will be your job to spot that and understand the underlying assumption. Things that come out of this event keeps the team motivated and engaged. A story from my experience – very early on my program, team gave a feedback that a lot of time was being spent in meetings. I made a team policy to keep Wednesday meeting free – in fact I termed it ‘No meeting Wednesdays’ and added that in my team’s calendar. This ensured no-one can book their time. This worked wonderfully well, and team members knew that they can be stay focused on that day without anyone calling them to meetings.
Two other things that you can try when you are sprinting are handover and kickoffs –
Kick-off – This is a quick 15 mins discussion between developer (IT example) picking the story, PO, BA and QA (Quality Analyst) to re-align themselves.
Handover – This is a quick 5 mins discussion (virtually/face-to-face) where developer explains to QA what he has worked on. It’s also a quick check for the developer to ensure al the acceptance criteria were met, and unit tested before handing over to QA.
In short, 2 definitions, 5 main events and 2 transition activities should get you going. Let me know what you think of this – again this is something that worked for my team – if you have read my previous article, you will know that this is the team I am most proud of.
If you want to know anything else on any other agile topics, do message me.
originally published on linkedin (https://www.linkedin.com/pulse/thinking-adopting-scrum-suraj-prakash/?published=t)