The values that I find important for ScrumMasters are being honest, fair, open,

never finger pointing, always analyzing and suggesting ideas, listening well, being
respectful to team members, and having open communication targeting the right
group of stakeholdersnot too large, which leads to unnecessary escalations, and
not too small, which can lead to team members feeling excluded; it has to be just
right. A ScrumMaster makes judgment calls in case of uncertainty, and has a quiet
and confident demeanor. All of these values that are hard to quantify make
someone a good ScrumMaster. Of course, having knowledge of agile principles and
techniques, exposure to successful agile implementations, prior coaching and
mentorship experience, and possessing technical knowledge are all important, but
they can be acquired. Values and instincts cannot.

fighting fires, removing impediments from the team's progress

educating people both inside and outside of the team about Agile and Scrum

coaching / mentoring team members for better performance

solving conflicts within and without the team

helping the Product Owner and the team groom the product backlog

shielding the team from the outside world so that they can focus on their
work

ensuring the team can keep a consistent pace over the long term (e.g. they
aren't overloaded)

Bringing someone for this role may be appropriate because no one on the related
team has the charisma or presence to keep the meeting in order, moderate
disputes, etc. This personality characteristic is incredibly important for the role
regardless of whether you carefully word that fact to parties who may need personal
development to not feel 'wounded' by hearing it.

This one is slightly tricky and diplomatic. I will suggest to the VP the current
business objectives the current project I am handling as a scrum master. With that I
will try to explain him the consequences of divided focus will result against the two
projects.

There may be couple of points to evaluate:

The sprint length is not chosen accurately. The length may require bigger
duration.

The PO has not set the requirements very clear in the PBIs and the team may be is
struggling to get the requirements clear. Due to this may be lot of time is wasted in
getting a single story in done state. I will collaborate with the team and the PO for
clearly setting the requirements by the PO.
The team is having some impediments like internal conflicts, issues,
communication gap, knowledge gaps etc which may be stopping them to
collaborate 100%. I will try to analyze as SM on to these factors and try to remove
them.
There may be some external distractions also. I will try to remove the distraction
by ensuring that the team remains focused

To remain focused is the basis for success of any agile framework. I will handle only
coach a single team to ensure that I am always focused in my approach towards the
team. In some extra ordinary case I may take up another team for coaching.

The ScrumMaster facilitates by creating a "container" for the team to fill with their
ideas and improvements. The container can hold questions, an agenda, or some
other flexible structure, giving the team just enough of a frame to stay on purpose.
It also promotes an environment for richer interactions, a place where ideas can be
heard
Facilitate the Daily Scrum Daily Scrums improve communications, eliminate other
meetings, identify impediments to development for removal, highlight and promote
quick decision making, and improve the development team's level of knowledge.
Offer observations afterward. Ask the team, "May I offer you some observations
about the Daily Scrum?" If they say, "No," then let it drop. If they say, "Yes," then
deliver your observations succinctly, without judgment, and with a sense of curiosity
that will invite their introspection. If a conversation happens and they figure out how
to hold better Daily Scrums next time, that's great. If conversation doesn't happen,
that's acceptable, too.
If you ask the question, "Do you have any new impediment to report?" and the team
member answers, "No. . . ," then: Make sure team member is on time with the
committed task (a delay may hide an impediment). Make sure team member has
not committed to more than two tasks at the same time (team member is probably
blocked, waiting for someone else -- maybe someone outside the team -- to
complete a task). Make sure team member is reporting with detail and specificity
what team member achieved since the last meeting. Think about whether the way

the team has chosen to accomplish the sprint objectives is the fastest and most
straightforward way, and eventually stimulate them to think outside the box and
inspect and adapt
Facilitate sprint planning Sprint planning requires a very light touch in facilitation,
even in the beginning. The ScrumMaster has two main jobs when preparing for
sprint planning: Prepare a structure (the event "container") together and that
ensure the product owner has prepared and refined the product backlog for the
sprint planning. If you offer teams a structure they can use to conduct the
mechanics of sprint planning, they can typically do it on their own. A set of agenda
questions or the list of things you are trying to achieve with sprint planning works
well as a structure. Whatever structure you use to guide the team, ensure that it
supports the purpose of sprint planning. The second job requires the product
owner's engagement and hard work. Often, the product owner works with the team
to refine the backlog, which includes the team's estimate of effort for every item.
This can happen throughout the sprint or in a meeting a few days prior to sprint
planning.

The idea behind the fixed length sprint is to provide a understanding between
development and the customer (or PO) when something new (and working) will be
available, and to define the length of the feedback loop, which is equals to the
length of the sprint.
In other words, the customer will know that they will get something in 2 weeks,
which works, and the development team will know that they'll receive feedback on
their work and know more about the upcoming work in two weeks. That's
predictability.
Let's get back to the feedback part. The length of the sprint helps you find the right
balance in work. You cannot really take more work than you can do in say two
weeks, so an agreed length can take of an unnecessary pressure from the
development team.
If your feature set takes three weeks, then you have to find way to break it down
into smaller tasks or user stories. The whole idea behind Scrum is to shorten
the feedback time. If you spend three weeks on a user story you'll get feedback
minimum in three weeks. If you manage to break it down to three, one-week long
user stories, the first feedback will arrive in one week, which is extremely good.
When organizations are new to Agile -- or even after they've been practicing Agile
for a while -- they often struggle to decide on the duration of a sprint or an iteration.
Executives, managers, and teams may organize sprint lengths without

understanding the benefits and penalties that the organization itself, and/or the
client, may face in meeting their strategic business objectives. If you asked a
product owner or manager, "How do you want to plan this release?" you may hear
something akin to "Let's see," a suspended judgment about velocity. Or "We'll divide
the total program volume by our velocity to get the duration for this release." This is
fine, but when you are planning a release, there are many more items to worry
about than your end date. How you can help bring more ROI and earlier payback for
the company? How you can avoid continuous changes to a system that is under
development? There are guidelines every product owner and team should consider
before they decide on a sprint length. These guidelines need to be implemented on
a case-by-case
Factors to consider when making a decision about sprint length
An unstable market Sprint lengths give clear visibility into what the team is planning
to deliver over a period of time. In today's world, things are changing so fast;
business and program priorities may change during the time it takes to deliver any
particular feature. In the case of an Android market app, for example, you may note
some features that were available on paid basic and now are available free of cost.
Hence investments made to develop any application that is already passing through
the market window is not worth it
Unstable teams Resource shuffling is one factor that may impact team productivity.
In order to maintain a sustainable pace, the ScrumMaster and product owner should
understand their organization, culture, and priorities. When you keep sprint lengths
short, at one to two weeks, it helps the team stay focused and minimizes their
distractions; on the other hand, if you have a four-week sprint and your team
structure is volatile (due to various reasons, such as priority changes, support
requests, staff on unplanned leave, multitasking, etc.), then you have to face the
issue of team distractions productively. Small sprint lengths keep teams focused and
keep distractions to a minimum.
Risk and control of uncertainty Uncertainty may come in a number of forms. It may
involve customer expectations about product behavior, or determining team
velocity, or determining the technical and requirement details about the project at
the time of release planning. More risk and uncertainty can be handled in short
sprint lengths. If you are completely in new product development and requirements
are not clear, and even the stakeholders are not clear about the requirements, then
the risk of developing the wrong product can be reduced by considering one- or
two-week iterations so you can get fast feedback from the customer and other
stakeholders.
Establishment of stable velocity When you are planning any Agile project, the best
way is to look at the velocity of the team and plan your work accordingly. Past
experience shows that if the team is new to Agile, you should run short iterations.

When you have short sprint lengths, the team is focused and its members are more
connected with each
Release length Product owners have confirmed that short iterations enable them to
get client feedback faster, developer estimates faster, and faster updates to plans,
thereby shortening the whole feedback cycle. Any project must have at least four to
five such occasions for stakeholders to provide their feedback
Too much WIP If you execute four-week sprints, then stories are not considered done
until they are reviewed and accepted by the PO and respective stakeholders. Once
user stories are accepted, then either the project increment will be available for the
internal customer or it will be directly delivered into the market, if the organization
plans to deploy a solution after every sprint. Once it is available in the market, it will
generate revenue, and anything that does not generate revenue is waste. If you
have longer sprints, then customers need to wait too long to enjoy the benefits of
sprint increments, there will be more variability, and the team will lose focus

If PO has cleared the story point as done in sprint review and rehected by
stakeholder then I will consider it done but will add additional PBI to the product
backlog to meet the stakeholders requirement. If PO has rejected then it is said to
be not done and story point goes back to the PB for repriortization/rework.
The current team in consideration will be different from the previous team in terms
of ability, agility, confidence etc. so In my opinion it will not be prudent to use
previous teams estimation. I will like to have my current team estimate the story
points.

Velocity is an extremely simple, powerful method for accurately measuring the rate
at which scrum development teams consistently deliver business value. To calculate
velocity of your agile team, simply add up the estimates of the features, user
stories, requirements or backlog items successfully delivered in an iteration.