So, you want to be a Scrum Master?
Let’s start with the basic list of top skills outlined in the LinkedIn research:
Agile Methodologies,Software Project Management, Scrum Requirements Analysis, SQL
- Maybe, “Agile” in general is an increasingly a kind of management fab but a trend the moment. Yet, what we can state without a doubt is that Scrum has turned out to be exceptionally famous for software development purposes. Demand for prepared Scrum specialists is on the ascent as is the market-passage of new experts from other project management branches, likely trusting that understanding one or two Scrum books will be adequate.
- If you are hoping to fill a situation for a Scrum ace in your organization, you may locate the accompanying 38 interview questions helpful to distinguish the correct applicant. There are gotten from my ten years of down to earth involvement with XP and in addition Scrum, serving both as Product owner and Scrum master and also talking with many applicants in the interest of my customers.
- Scrum isn’t a methodology, however a framework. There are no guidelines that apply to every last situation, simply best practices that have worked in different organizations previously. Henceforth, you should make sense of without anyone else what is working for your organization– which is a process, not a destination.
- So, the role of the Scrum ace or agile mentor in my comprehension is essentially about leadership and training, however not about management. What’s more, undoubtedly, the Scrum Master role isn’t about “process enforcement”. Which is likewise the reason that the store contains to a huge part addresses that are tending to a competitor’s soft skills.
- The questions are, in any case, neither suited, nor intended to transform an unpracticed questioner into a coordinated master. Be that as it may, in the hands of a prepared professional they bolster making sense of, what applicant has really been working the agile trenches before and who will probably be an imposter.
25 Questions a new Scrum Master should ask the team to get up to speed
-
HOW LARGE IS YOUR PRODUCT BACKLOG?
We don’t have confidence in product backlogs that are bigger than what the team can deal with in three, maybe four sprints. If the product backlog exceeds this threshold, the product owner might be in requirement for some help.
-
WHAT IS THE TYPICAL AGE OF A USER STORY IN THE PRODUCT BACKLOG?
Again, we don’t trust in the value of a user story that is 5 months old. Furthermore, a “yet we have been working on it ever since” is an excuse in my eyes.
-
WHAT IS YOUR AVERAGE LEAD TIME FROM AN IDEA BEING ADDED TO THE PRODUCT BACKLOG TO ITS DELIVERY?
Nobody could answer that question in the before-mentioned session. However, it is really one of just three metrics that can provide some insight on whether “agile” has been successfully adopted by your organization.
-
DOES YOUR PRODUCT BACKLOG CONTAIN USER STORIES NONE OF THE CURRENT TEAM MEMBERS IS FAMILIAR WITH?
Maybe those should be re-estimated with the current team members to make sure the value is estimation accurate?
-
HOW OFTEN ARE YOU GROOMING THE PRODUCT BACKLOG?
That should be done at any least once a week depending on the state of the project.
-
ON HOW MANY USER STORIES ARE YOU WORKING IN PARALLEL DURING BACKLOG GROOMING?
In a perfect world, a team should not be working on more user stories than it can deal within the next two or three sprints. Something else, the risk of allocating resources on user stories that may never make into a sprint backlog becomes too high.
-
HOW LONG DOES THE GROOMING OF A TYPICAL USER STORY TAKE?
The grooming should not be taking more than one to two sprints.
-
HOW ARE YOU CREATING USER STORIES?
There is a tendency to observe that product owners become more a kind “technical writer” of user stories which at that point get evaluated by the team. we recommend, in any case, to transform user story creation into a join effort of the whole team.
-
WHERE ARE YOU DISCUSSING USER STORIES?
Just during grooming sessions or also on Slack or by means of comments on tickets, for example?
Each team has it own habits, and maybe commenting in Confluence, Jira, Github or utilizing Slack is a effective means of communication in your organization. As long as of this happens before a user story is selected for a sprint backlog, this should to be fine. Discussing its essentials afterward is an problem, however.
-
DO YOU APPLY A “Meaning OF READY” STANDARD TO YOUR USER STORIES?
That should indeed be a standard. An volatile velocity can at least partly be credited be attributed to the lack thereof.
-
IF SO, OF WHAT CRITERIA IS YOUR “Meaning OF READY” COMPOSED OF?
Typical criteria for a “definition of ready” are: The description is available, acceptance criteria are defined, the story can be delivered within a sprint, all UI deliverable are available, every dependencies are identified, performance criteria are defined, tracking criteria are defined and the story is valued by the team.
-
WHO IS WRITING ACCEPTANCE CRITERIA AND IN WHAT FORMAT?
It should to be the product owner in collaboration with the team to create a shared understanding of what needs be build.
-
HOW ARE YOU ESTIMATING THE LIKELY EFFORT OF A USER STORY?
An estimation poker would be valuable.
-
ARE YOU ESTIMATING IN MAN-HOURS OR STORY POINTS?
Assessing worker hours is betting than not evaluating at all. In any case, we lean toward user story points, particularly if the application in question is burdened with legacy code and/or technical debt. Predictability and stakeholder communications becomes easier this as they are featured with a built in buffer.
-
WHAT IS A TYPICAL DISTRIBUTION OF STORY SIZES IN YOUR SPRINT BACKLOGS?
This one tries to make sense of, where the responsibility sweet spot of the team, based on the sprint backlog organization. To my observation, teams often work in a more successful way, when a sprint backlog includes a few larger user stories, some medium valued stories and a few small ones.
-
ARE YOU RE-ESTIMATING USER STORIES AT THE END OF A SPRINT? PROVIDED THAT THIS IS TRUE, UNDER WHICH CIRCUMSTANCES ARE YOU DOING SO?
That should to always be done if a user stories turns out to be way its original estimation.
-
WHAT WAS YOUR VELOCITY OF THE LAST THREE SPRINTS?
The team should know its velocity, how could it otherwise possibly develop?
-
HOW MANY USER STORIES ARE TYPICALLY NOT FINISHED WITHIN A SPRINT AND FOR WHAT REASONS?
In the event that the team is bullish and picked more user stories than it probably at the beginning of the sprint, so be it—nothing to worry about. Likewise, there are other incidents that may negatively effect the team’s actual velocity, e.g. sick leave or a critical bug a few days into the sprint. If the team, be that as it may, is regularly leaving user stories on the board because estimations weren’t right, this is a sign for concern.
-
ARE YOU CHANGING USER STORIES ONCE THEY BECOME A PRODUCT OF A SPRINT BACKLOG? WHAT’S MORE, IF SO, UNDER WHAT CIRCUMSTANCES?
All things considered, making them smaller if the team runs into an problem is certainly not great, but acceptable—if the user story in its reduced frame still delivers an value. Making it larger after the sprint planning is, however, not acceptable.
-
DEFINE AND DISCUSS AT LEAST THREE KEY TEAM GOALS FOR THE PROJECT.
Some of the answers may seem obvious, meet our deadline within our budget, yet this discussion can often bring out different objectives which are not evident to the Team at first. It can enable the Scrum master understand Team motivations and dynamics.
-
WHAT ARE KEY SUCCESS FACTORS TO ACHIEVE OUR TEAM GOALS?
Defining and discussing key success factors, minimizing the impact of dependencies, can help identify project level impediments, risks, and issues which the Scrum Master can begin to address. It likewise is a good benchmark to survey and refresh as the project progresses.
-
WHAT DO TEAM MEMBERS HOPE TO ACHIEVE WITH THIS PROJECT?
We like get a sense of peoples personal goals for the project in addition to the Team objectives we will establish collaboratively. Having this information can help keep to people motivated over the span of the project. A few people may want to learn new technologies, be a part of a high-performance Agile Team, or have other goals.
-
WHAT TYPE OF WORK ENVIRONMENT DO WE WANT TO CREATE ON THIS PROJECT?
This question can stimulate good discourse about how Team Members need to collaborate with one another to achieve the project goals. Regularly the discussion focuses on trust, communication, collaboration, and respect, yet it’s good to make sure there is some agreement by the team about what is important.
-
WHAT CAN WE DO AS A TEAM TO MAKE SURE THAT WE SUPPORT EACH OTHER TO ACHIEVE OUR TEAM GOALS?
This question can help the Scrum master understand how team members understand the importance of making commitments as a team as opposed to as people. It can likewise enable the team to set up casual agreements about the requirement for everybody to help one another, to go up against roles outside their specialty, and trust their team when they have to request help.
-
WHAT SHOULD WE DO WHEN WE ARE NOT ACHIEVING OUR GOALS OR NOT SUPPORTING EACH OTHER?
Clearly, this can be tended to in a retrospective, but having the discussion early can be helpful to understand how team members see how these situations should be handled. It can help establish the requirement for transparent communication built on trust.
For more blogs: https://blog.aleph-technologies.com/
Aleph Technologies is a premier IT training and staffing group with state of the art facilities based in Dallas, Texas. Aleph Technologies specializes in providing hands-on classroom based and onsite IT certification training courses taught by expert instructors with practical industry experience.
