Beyond Scrum Events

Even though Scrum is still the most adopted agile framework, around 58% according VersionOne 2016 research, its rules, roles, events and artefacts are frequently misunderstood. People commonly apply this framework without understanding the real purpose that stands behind it, loosing its main benefits.

Below I bring some of my thoughts to get good value out of the Scrum Events.


Sprint Planning:

What do you commit to? Sprint Backlog? Should it be frozen after Sprint Planning? And what if any unexpected thing happens with your team or something new emerges? After all, the world is complex, isn’t it?!

Therefore, you should craft your Sprint Goal! The Sprint Goal underpins the reason to run that sprint, it gives a clear view of what the team will pursuit during this timebox. After that, the team will FORECAST how they will achieve it by selecting Product Backlog Items (PBIs).

Would it be fair to say that there are many ways to achieve a goal? If you agree with me, why are you going to keep using one single way even though you found out a better one just because you have “committed” to that initially!? It sounds silly, doesn’t it?

Your Sprint Backlog can and most likely will change whenever something new emerges throughout the sprint, however, the Sprint Goal has to remain untouched. If the Goal is not valid anymore, the sprint should be cancelled but you should try to avoid it as much as possible, a lot of ravages can happen here. As soon as something new comes up, the Dev Team and PO get together and reajust the Sprint Backlog but have to keep the same Sprint Goal. This sounds like Inspection and Adaptation and all that Scrum is about. So, why are you going to lose this benefit?

NOTE: The aforementioned is not Scope Creep

You COMMIT to the Sprint Goal and FORECAST how (Sprint Backlog) you will achieve it!

(Please, go back, read the statement above again and repeat it loudly as many times as needed until it echoes in your mind uncontrollably 🙂 )

Let’s make an agreement here: stop using “Commitment” for Sprint Backlog and start using “Forecast” right now! It will make everyone’s life easier to cover unexpected things that come up during the sprint and keep the team focused on the increment (working software) aimed by the end of the sprint.

HINT: Good backlog refinement process = Effective Sprint Planning.


Daily Scrum:

Daily Scrum is another opportunity for inspection and adaptation. You will inspect your current status towards your goal. But commonly you hear teams using the question below:

  1. What did you do yesterday?
  2. What are you going to do today?
  3. Do you have any blocker?

This seems (is!) Command and Control approach where the Dev team is providing status report. If it’s not relevant to achieve the Sprint Goal, possibly it shouldn’t be discussed during this meeting.

Instead, you should use something like:

  1. What have we accomplished since the last daily Scrum meeting to achieve our Sprint Goal?
  2. What do we plan to do on the next 24 hours to progress towards our Sprint Goal?
  3. Do we have any impediment preventing us to achieve our goal?

HINT: Is your team always looking at the Scrum Master during this meeting? Try to stay behind them to see what happens and remember, the daily Scrum is for the Dev Team!


Backlog Refinement:

Backlog refinement is the process through which product backlog items are reviewed and more detail is provided to ensure that there is greater clarity for that item. Even though this is not a official Scrum time-boxed event, there is a lot of value in it mainly for non-mature teams.

If you see requirements dressed up as a backlog or wish list for birthday gifts, it’s time for improvement:

  • Requirements do not support the emergence of requirements and;
  • Huge backlog that contains anything and everything that we might ever need are hard to prioritize and limits the ability to evolve based on customer feedback.

A good source for backlog management is Roman Pickler’s book: Agile Product Development and his blog.

HINT: User Stories are in between a desire (too fuzzy) and a requirement (over-specified/over-detailed). The main purpose of US is to foster discussion/collaboration/communication.


Sprint Review:

The main purpose of this event is to show transparency and inspect/adapt the product, not to impress or create excitement.

Prepare upfront (keep it to a minimum) and focus on the sprint goal/increment (comparing sprint goal to the increment). But, if it’s possible, why don’t you get PO’s feedback just-in-time during the Sprint? The more the Dev Team engages with PO throughout the sprint, the bigger is the chance of a successful Sprint Review.

Involve stakeholders and make it useful to everyone. Avoid formal presentation and slides.

HINTS: Agenda helps to keep it productive!

 


Sprint Retrospective:

In this meeting the Scrum Team will reflect upon people, tools, practices, quality, process, etc. They will look where there is room for improvement and what experiments might be worth to put in place in order to learn and build a better solution.

Do you have actionable improvements/experiments to put in place after the end of this meeting? Do you have time to work on them during the next Sprint? How frequent do you follow them up? They will likely lose meaning and will be only a pro-forma if you don’t have time to work on them, follow them up, check and adapt if needed.

Don’t be afraid to make mistakes! Validate your assumptions! Run experiments! (PDCA)

Additionally, don’t wait until the end of the sprint to gather data and improve, do it on daily basis. It’s worthwhile to check the Popcornflow by Claudio Perrone.

Also, PO your attendance is very important to Retrospectives. Make any extra effort needed to engage in this meeting.

Finally, inspect and adapt having fun. It may take some time to ice break but it’s worth! There are good resources that can help you with:

HINT: Agenda helps! Engage people making this fun!


Final Hints:    

  • Apply ROTI – Return on Time Invested (open or anonymous) – on every event, you’ll be surprised by the result! This is a valuable input for adaptation!
  • Definition of Done (DoD)? Do you have one? If not, do it now and use it!
  • During your events visualise progress; therefore, create information radiators, not information refrigerators!
  • Grant autonomy, foster mastery and provide purpose to your teams, and you will surprised by their outcomes!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s