The Sprint Meetings

The sprint is the heartbeat of the Scrum cycle. It is bookmarked by sprint planning at
the start and by the sprint review and sprint retrospective at the end. The length of the
sprint is fixed and is never extended. Most Scrum teams choose two, three or four
weeks as their sprint duration. Each day during the sprint the team holds a daily
Scrum meeting. Every meeting in Scrum is strictly time-boxed. This means that is has
a maximum duration. It does not means that it needs to occupy this full time. For a 30
day (or four week) sprint the time boxes for planning 1 & 2, review and retrospective
are set at four hours each. For shorter sprints they should be adjusted in proportion to
the sprint length.
Some key attributes of the meetings are described in the following sections. First,
though, I have collected a few experiences I think are worth sharing.

• I find two-week sprints a good length to start with. After three sprints, let the
  team re-assess the sprint length.
  
• Teams need three sprints to grasp the new concepts, break down old habits
  and start to gel as a team.
  
• Never do sprint planning on a Monday morning. The team is not yet at its
  best and it is the most common day for holidays and sickness. Never hold
  reviews or retrospectives on a Friday afternoon. The team is tired and
  thinking about the weekend. Therefore choose sprint boundaries on
  Tuesdays to Thursdays.
  
• Teams running two-week sprints might be tempted to hold all sprint
  boundary meetings in one day. In other words, start the day with the review,
  then the retrospective; after lunch do sprint planning parts 1 and 2. The
  thinking is to get all the meetings out of the way and have 9 full days to do
  the work. In my experience there are two problems with this approach:
  
  • The team does not get that these meetings are part of the work—in fact
    the most important part to get right!
    
  • During the last part of the day—sprint planning 2—the team is brain-dead.
    
    Yet, as always, let the team try it out if they so wish!
    

Sprint Planning - Part 1
Part 1 of sprint planning (SP1) is really a detailed requirements workshop. The product
owner presents the set of features he would like and the team asks questions to
understand the requirements in sufficient detail to enable them to commit to delivering
the feature during the sprint. The team alone decides what it can deliver in the sprint,
taking into account the sprint duration, the size and current capabilities of its
members, its definition of DONE, any known holidays or leave days and any actions it
committed to during the retrospective held just prior this meeting.
The product owner must be present during this meeting to lead the team in the right
direction and to answer questions—and they will have many. The ScrumMaster must
ensure that any other stakeholder needed to help the team understand the
requirements is present or on call.
Any new backlog items for inclusion in the current sprint and not previously estimated
will be sized immediately during this meeting. This not, however, an excuse to avoid
grooming the backlog—see below!
At the end of SP1 the team commits to the Product Owner what they believe they can
deliver in the form of running tested features. An experienced team may use historic
velocity as a predictor ('yesterday's weather'). This is known as velocity-based
planning. My recommendation to most teams is to do commitment-based planning.
The backlog items the team has committed to is called the selected product backlog.

Sprint Planning - Part 2
If part 1 is a requirements workshop, part 2 of sprint planning (SP2) is a design
workshop. In this session the team collaborates to create a high-level design of the
features it has committed to deliver. An outcome of this session is the sprint backlog,
or the list of tasks that the team collectively needs to execute in order to turn the items
in the selected product backlog into running tested features. This set of tasks is called
the sprint backlog and is most often represented on a physical task board.
During SP2 the team may have additional questions regarding the requirements. The
ScrumMaster must ensure that the Product Owner and, if necessary, other
stakeholders are on call to answer them.
Design, as everything else in Agile, is emergent. Also, the meeting is time-boxed. So it
is normal that the team won’t get the design perfectly done in this session and will
discover more tasks during the sprint. This is not a sign that something is wrong. They
will simply grab a post-it note and pen and create more tasks whenever necessary
during the sprint.
You will know that SP2 is working when the team is gathered together
around the white board discussing noisily or even arguing about the 'best' or
'right' way to implement a feature.

(Do Better Scrum)

Enjoy Programming!!!

Roles Introduction (SCRUM)

The scrum process constitutes various roles and are discussed below:

Roles Introduction
There is no Project Manager role in Scrum. The responsibilities of the traditional project
manager are divided over the three roles in the Scrum Team:

• The Product Owner manages the product (and return on investment)
• The ScrumMaster manages the process
• The team manages itself.

This is challenging to individuals who currently fulfil this role and to managers in
organisations in which they work. Michele Sliger and Stacia Broderick have written a
helpful guide to the transition from Project Manager to Agile Coach [Sliger and
Broderick 2008].
There are no appointed leaders of the Scrum Team beyond the Product Owner and
ScrumMaster; none is required. The need for line managers is reduced, as teams
manage themselves to a great extent. It is not uncommon for 50 team members to
report directly to a single line manager in an organisation that has made the transition
to Agile.

Self-organisation
Self-organisation does not at all imply a laissez-faire approach; on the contrary, selforganised
teams are highly disciplined. They are given full autonomy and carry
correspondingly greater responsibility for delivery accordance with their own
commitments. They are encouraged to take reasonable risks and to learn through
failure and self-reflection. High trust and high commitment is an automatic outcome of
truly self-organising teams.
Teams new to Scrum will require some encouragement to explore their new, broader
boundaries and to take ownership. They frequently need to overcome strong ‘muscle
memory’ of the poor ways in which they were managed and worked, sometimes for
years.
Self-organisation is not an option in Scrum; it is a core principle. Without this, highperforming
teams will not happen. Caveat emptor!

Product Owner
The responsibilities of the Product Owner role are:

• Working on a shared vision
• Gathering requirements
• Managing and prioritising the Product Backlog
• Accepting the software at the end of each iteration
• Managing the release plan
• The profitability of the project (ROI)

Metaphor: The Product Owner is a CEO.

ScrumMaster
The responsibilities of the ScrumMaster role are:

• Empowering and shepherding the team
• Removing impediments
• Keeping the process moving
• Socializing Scrum to the greater organisation

Metaphor: The Scrum Master is a facilitator, coach, mentor and bulldozer!

Team
The responsibilities of the Team or Team Member role are:

• Estimating size of backlog items
• Committing to increments of deliverable software and delivering it
• Tracking own progress
• Is self-organising—but accountable to the Product Owner for delivering as
  promised

Enjoy Programming!!!

Online Escrow Payment Flow Algorithm (Instructions Set)

On the basis of analysis to implement Escrow Payments, below is the generic algorithm:

Online Escrow Payment Flow Algorithm (Instructions Set)

State – 1: Buyer requests for the service* and pay the amount through any payment gateway. There should be commission and/or transaction fees included in the amount, then
Total Amount = Amount to seller + Commission and/or Transaction Fees.
At this moment, the status of escrow process will be "0"(zero).

State – 2: The amount that buyer paid will go to the Escrow* (Admin) account using any specific payment gateway.

State – 3: Both the parties (buyer and seller) will be informed (through email and/or any other mean) after successful payment with all required details. The status of this escrow process will be set to "1" i.e amount has been paid by the buyer.

State – 4: If the payment was not successful, then buyer will be informed about it and escrow status will be set to "-1". Seller may be informed about the initiation of this process and this will depend on the type of service.

State – 5: Service will be provided to "Buyer" by the service provider which should follow necessary set terms and conditions which will depend on the type of service.

State – 6: The required time slap will be provider to "Buyer" to raise dispute against the payment paid for the service. If dispute arises then this would be the duty of Escrow (Admin) to resolve that dispute and there should be set parameters which will be used to resolve dispute. In this condition "Dispute" status will set to "1" from "0" and payment will be blocked, "dispute resolution time" will be added to the "Escrow Complete" time.
This whole process will depend on the type of service and several different service specific approaches will come handy.

State – 7: If resolution of dispute goes in the favor of buyer then "Dispute" status will be set to "2" else
it will be set to "3".

State – 8: Dispute should be resolved in the set interval of time i.e “dispute resolution time”. After this set interval of time, check “Dispute status”. If its value is “2”, then transfer amount back to buyer account after deducting commission and/or transaction fees else transfer set amount to the account of service provider.
Now set escrow process status to “2” i.e Escrow complete.

State – 9: If all goes well and there is no any dispute, after completion of “Escrow Complete” time, transfer set amount to the account of seller and set escrow process status to “2” i.e Escrow complete.

(Rajesh Bhatia)

Enjoy Programming!!!