Showing posts with label sprint activity. Show all posts
Showing posts with label sprint activity. Show all posts

Tuesday, 1 April 2014

Rules For The Daily Scrum Meeting – What Every Member Should Do To Make The Sprint Successful

The daily scrum meeting rules
The daily standup or the daily scrum meeting is very important while implementing scrum. The purpose of the daily standup is to initiate the sprint activity for the particular day, with a little bit of discussion pertaining to what was done in the sprint the day before i.e. yesterday, and what the team plans to do on the particular day i.e. today. It is imperative for the team members to follow rules which can help to implement scrum in a successful manner. Moreover, the team members are also required to maintain a certain decorum while participating in the daily standup.
 
The important rules required to conduct a beneficial standup and implement scrum in a healthy manner can be briefly summarized:
 
1. Held in the same place
Ideally, the daily scrum should be held in the same place, and at the same time every day. The best time to hold the meeting is in the morning, before the development team initiates the actual daily sprint. The potential of the team can be best tapped when members are fresh, and open to ideas. 

2. S
hould be time boxed
The meeting should be time boxed and not extend beyond the stipulated 15 minutes allotted for it.

3. E
ncourage active participation
The scrum master should encourage active participation and ensure the members are collaborating during the meeting, as well as during the sprint.

4. A
ttend the daily standup
All team members, including the product owner and the scrum master should ideally attend the daily standup. In case of a distributed team, the remotely working team members should participate using online media and tools .

5. M
aintain timings and must be prompt
The members attending the meeting should maintain timings and must be prompt. They should be mentally prepared with their brief presentations and what questions they need to ask, if required, during the meeting.

6. E
ach member gets a chance to talk and discuss
The scrum master should ensure each member gets a chance to talk and discuss without any inhibitions. Irrespective of the process you follow about which member should speak first, each individual should disclose what work was done in the prior sprint, and what he or she plans to do on that day.

7. T
hree important questions
The three important questions:
  • What activity was done the day before?
  • What activity is planned for today?
  • Are there any issues or problems which impede the sprint process?
Should be discussed in the meeting by each development team member participating in the daily sprint.

8. S
hould refrain from asking questions other than those mentioned
The team members should refrain from asking questions other than those mentioned in point 7. The discussion should not include topics pertaining to designing, trouble shooting, fixing bugs, project analysis, etc.
 
9. Not indulge in gossip
Team members should not indulge in gossip or carry out any other discussion not pertaining to the daily scrum.
 
10. Only one individual speaks at a time
When the meeting is being conducted, only one individual speaks at a time. All other members should listen carefully, and make notes if required.
 
11. Address the team as a whole
The member should address the team as a whole, and not just focus or concentrate upon the scrum master while providing the feedback.
 
12. Query or problem is solved as soon as possible
During the meeting, if any team member requires help or guidance regarding a particular point or problem faced by the individual, the scrum master should ensure that the query or problem is solved as soon as possible.
 
13. Stakeholders should remain quiet and not intervene
Non-team members and the stakeholders can attend the meeting if they desire to do so, but they should remain quiet and not intervene during the meeting. They should not indulge in any activity which can distract the team members from carrying out the meeting in a proper manner.
 
14. Provide ample of room
Non-team members should provide ample of room to the development team so they have enough space to conduct the meeting, and make notes.
 
15. Scrum master holds the right
The scrum master holds the right to prevent any non-team member from attending the meeting if he or she deems fit to do so.
 
16. Any member not supporting the rules should be asked to leave
Any member, team or otherwise, not supporting the rules and regulations can be asked to leave the meeting and the vicinity by the scrum master.
 
Find out more, and download our free QuickScrum tool which can help you in implementing scrum in an effective and profitable way!

Why Sprint Planning Meetings Are Important While Implementing Scrum Methodology



Sprint planning is perhaps one of the most important aspects of implementing scrum methodology. It offers an opportunity to validate the product backlog and take up user stories for the sprint backlog – the list of requirements taken up by the team members for development purpose during the sprint activity. Sprint planning involves a team effort. The product owner carries out sprint planning with the help of the scrum master, and it requires an active participation by the team members to complete it in a successful manner. The team members divide the user stories taken up in the sprint backlog into individual development tasks. Subsequently, the team members take up tasks for development depending upon their levels of expertise and experience.   


What is the nature of the sprint planning meeting?
The planning meeting generally occurs in two parts – the first part involving the product owner and the scrum master, in addition to the team members. The second part is attended by the team members, who may recall the product owner to the meeting if they need his or her help.

The first part
In the initial part of the meeting, the product owner shares his or her vision regarding what should be included within the sprint backlog based upon the importance of the requirements, or the user stories, available in the product backlog. The person discusses the sprint goal with the team, and explains about what the investors and the stakeholders desire regarding the functionality associated with the product backlog items. The sprint goal is also decided and carefully explained to the team members. One of the most important aspects is the discussion related to the acceptance levels of the user stories i.e. what the user story should satisfy in terms of criteria to be considered as “completed” or “done”. Ideally, the team members should make notes during the meeting so they can remember about the specifics associated with each product backlog item. If any member is unclear about any aspect pertaining to the user story, or how it should be developed, he or she is free to ask during this part of the meeting and get his or her confusions cleared.

The second part
The second part of the meeting is succeeded by a break, usually the lunch break. This part is important for the team members since they have to discuss amongst each other how the sprint backlog items should be segregated and broken down into individual tasks. Each story should be broken down into smaller parts so the team can easily develop it. Thereafter, the individual members of the team unanimously decide as to who should take up which tasks. This part requires a proactive participation, and the members should volunteer to take up work. Generally, the work is taken up based on expertise possessed by the team member. More experienced members can take up more tasks, while less experienced ones tread carefully by taking up easier stories which can be developed without much complexity. Eventually, the list is completed as to which of the user stories will be “processed” and developed by which team member.    

Find out more, and download our free QuickScrum tool which can help you in implementing scrum in an effective and profitable way!

Monday, 31 March 2014

In Scrum, Can A Sprint Be Cancelled? If So, When?



Scrum framework and sprint
Scrum development is fundamentally about adapting to changes occurring during the product development cycle. Scrum levies a lot of significance to transparency, distribution of work, and incorporating changes even “late during the development stage”. Each individual associated with the implementation and working of the scrum framework is assigned a specific role. The person is strongly advised to perform within the boundaries specified by the role he or she is supposed to play, and not transgress the area of work under any circumstances. In scrum, the product owner too has a specific role to play, and is responsible for creating and maintaining the product backlog. The product owner has the final word while working out the list of requirements needed to develop the product – the user stories – which form the backbone of any product backlog. Each user story is further divided into individual tasks, which are taken up by the team members. These tasks are developed during the sprint activity. A sprint activity or simply the “sprint” is nothing but a “burst” of development activity undertaken by the team members, which generally lasts from two to four weeks as decided by the product owner. At the end of the sprint, a meeting is carried out which analyses how much development work has taken place, or how many user stories are successfully completed by the team members. So in many ways the sprint functions as the main essence, or the “heart” of the scrum process. Sprint plays an integral part in the scrum framework.

Can a sprint be terminated abnormally before it is completed?
Development teams are always instructed to complete their user stories as well as tasks well within the sprint duration. It is very important for the sprint process to be completed if the management is to achieve positive results out of scrum implementation. However, under some unusual or rare circumstances, sometimes sprints need to be “stopped” or terminated before it has a chance to run its full cycle. It is the product owner who decides if the sprint can or should be terminated or not.

Some of the reasons, which may induce the product owner to terminate the ongoing sprint, can be:

  • The stakeholders or the company management changes its priority regarding the product development
  • Market trends and/or changes make the current product development redundant or obsolete
  • A major technology change may introduce newer ways and methods of working
  • A better technical solution may offer a quicker and a more cost effective way of meeting the product development  
  • The management or the stakeholders may experience a financial crisis, or may not be able to financially support the development work
  • The launch of a new or better product may render the current development work superfluous and unnecessary
Find out more, and subscribe to the permanently free "limited users" QuickScrum tool which
can help you in implementing scrum framework in your projects!