Gaps in Scrum Approach!

Let me try to help. The Scrum Guide is a framework vs. a highly detailed methodology. It is not highly prescriptive. That is intentional. The primary thing to keep in mind is the Scrum Guide describes the "WHAT", but leaves a lot of the "HOW" open for teams to find what works best for them. As teams continually improve and try various techniques, they will find what works for them. That also may change over time as the team matures.

There may be more than one way (the "HOW") to do something described in the Scrum Guide. For example, from page 9 of the Scrum Guide in regard to Sprint Planning, it states "However, enough work is planned during Sprint Planning for the Development Team to forecast what it believes it can do in the upcoming Sprint."

Using that example, there are several ways (techniques) in which teams may decide how much work is enough for a sprint. Some teams use relative points to estimate and use average velocity to forecast. A different team may just agree to a specific number of Product backlog Items. Another teams may use hours, etc.

I believe the job descriptions you are seeing may use that idea as a way to discern experience and successes from the job candidates.

I hope this helps.

Hi Russel,

Thanks for the information. It really helps.

Are there any real world examples in this just like sprint planning you are talking about.

Thanks in advance

"The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours." How this coordinated plan is actually created is up to the Development Team.

Too often, "During the meeting, the Development Team members explain [three questions]" is interpreted as each Development Team member directly answers them. In doing so, the Daily Scrum event becomes a status report; the benefit of a collaborative team is lost. The intent with the three questions is to guide the Development Team to proper inspection and adaptation in the daily planning conversation.

Scrum is also recognized as "easy to understand; difficult to implement".

Scrum is framework and talks about "What" to do and not on "How" to execute. It is left to SM and team. Many people look at it as gap.

I understand numerous Retrospective formats or handling bugs etc. But also surprised to see "numerous Burndown techniques". Burndown is about your capacity utilization verification within a sprint. Mostly working capacity is measured in person days/hours hence we consumption is tracked in person hours.I take is as item in my watch list.

In doing so, the Daily Scrum event becomes a status report; the benefit of a collaborative team is lost.

+1
It's the reason why I wonder if the Daily Scrum shoudln't have a less sexy but more explicite name like "daily planning meeting"

Hi Ranjith,

I'm glad you found my reply helpful.

Here's another real world example. The Scrum Guide states the purpose (WHAT) of the Sprint Retrospective, when it should occur, and that the participants are the Scrum Team (WHO). It does not describe the HOW of the Sprint Retrospective in great detail. There are many articles, books, and blog posts about how to conduct a sprint retrospective. Try using your favorite web search engine for the search term "sprint retrospective" and you will find a lot of ideas, techniques and discussion about how sprint retrospectives can be done.

Again, the idea is for the Scrum Team to inspect and adapt as needed. This leaves the door wide open for the team to find the approach or technique that is just right for the team at that time. And, the team is free to try something different in the future and adapt as things on the team change. That's really what Scrum is all about--transparency, inspection, and adaptation.

Think of it as an analogy. Scrum is like the rules of a game, say basketball. The court is so long by so wide, players must dribble the ball, you get points for putting the ball in the goal.

The rules of basketball say absolutely nothing about what makes a good basketball team. Scrum master is like a coach who obviously knows the rules of basketball, but also knows lots of different techniques to teach the players in order to be a better team.

Great explanation, I like it.

Another thought specifically from the recruiters perspective, give that you have mentioned JD -

The recruiter wants to state, apart from knowing the rules and regulation of the Scrum framework,

- you should have hands on / expertise on different tools & best practices often used while implementing Scrum

- your understanding of the evaluation process for those tools and best practices

Hope it helps