After the team has picked the requirements from the Project Backlog, during the Sprint Planning Meeting, the team normally drafts a Sprint Backlog, the team starts working on the requirements and through a Daily Stand Up during the Sprint and updates the Sprint Backlog. Once the sprint is complete, the time comes to demonstrate working functionality. For this, the team and product owner gather together for Sprint Review. A Sprint Review is a meeting where the team demonstrates working software corresponding to project backlog items they have completed in a given sprint. There are some simple rules for a Sprint Review:

• The meeting is kept very informal. The team should not have to spend time preparing for the same beyond getting working software ready.
• Powerpoints, presentations, speeches and lectures are not allowed.
• You can only demonstrate working software.
• The preparation [working environment, arranging room] is done by the Agile Coach or Scrum Master.
• The meeting generally lasts about 1 hour per week of work [but this obviously can change depending on number of team members working for the project].
• The whole team, product owner or customers and stakeholders participate in the Sprint Review Meeting.

Of the above focus on “working software” is very important. This keeps the teams focus on delivering working software and adopting processes which aid delivery of the same. Thats another reason why any aids like PowerPoint slides or lectures are not allowed. The team would typically demonstrate each code it has written either through GUI, mock objects or through API calls. Actual working software allows product owner or customer to get first hand experience of the working features and based on the same provide feedback to the team. The feedback to the team is typically of these components:

• Whether they completed enough requirements
• Whether they completed requirements quite early
• Whether they understood the requirements and translated them to working features well enough

All three help the team and product owner plan for the next sprint better. At the end of sprint review meeting, Agile Coach or Scrum Master would announce the date for next Sprint Review and confirm the date for next Sprint Planning session. This sets the tone for the next sprint. After the Sprint Review Meeting, the team moves towards the Sprint Retrospectives.

The Sprint Review also works as a feedback channel for the Product Owner in some ways. The Product Owner invites stakeholders and customers who give her the actual feedback which she can factor into her requirements for future. She can then edit or delete any requirement or add new ones. In addition, they help the Product Owner identify the correct priority for requirements and minimize the biggest risk of all - developing the wrong thing as well as the second biggest risk - developing the wrong thing, the wrong way. Hence, Sprint Review is basically a “feedback, inspect and adaptation” channel in an Agile Development Framework.

Popularity: 30%

Posted on February 28th, 2008 by admin
Filed under: Assessment, Collaboration, Introduction, Practices | No Comments »

Lets start with a quick snapshot of a daily stand up:

• Who should attend - the team including the scrum master/ agile coach/ process coach
• Who should not attend - Customers, management or product owners
• Why should it be standing - This is to help:
  • Keep everyones focus - you are more alert standing than sitting
  • Quick - you can stand comfortably only for a while
  • Able to be conducted right where the team sits
• How does everyone stand - In a huddle, facing each other
• Why should I listen to what “A” is working on - You guys are the same team working on same project or team goals, and you would like to know if something A is doing is useful to you or you would be able to help/ provide insight to A. If team members are still not convinced, the process coaches should find out why the team does not have a “shared committment and a vision”.
• What if customer wants to attend - There are two aspects that you should consider here.
  • Why does the customer wants to know this? Does he/ she not see enough business value being delivered by the team
  • Provide them sprint backlog or a consolidated “team wise” work done. If that wont work, allow them to attend without speaking anything.
• What if A is not available - Do a tele-call in or have a proxy in place or probably send in an email summary
• How long should it last - Less than 15 minutes [roughly around 1 minute per person]
• What time it should take place - Same time, every day of the sprint
• Who decides what time it takes place - The team, the decision can be facilitated by the Scrum Master
• What is A and B can’t make it on time - The team has to figure out a way
• What is the agenda - Basically every person answers 03 questions:
  • What did I do since our last daily stand up?
  • What will I do till our next daily stand up?
  • Is there something that is holding me up?
    • This is all. There are no other aspects discussed like technical details or dependencies etc.
    • To keep the team focusses, its useful that the team talks of things they are doing/ going to do in terms of the sprint backlog
• When do I discuss the problem holding me up - Raise a hand and ask concerned people to stay back after daily stand up and discuss it then OR come up with an alternative plan that does not disrupt the flow of above agenda and make daily stand up more than 15 minute
• Who starts first - No rule set. The team can decide. Some creative examples are late comers start first, pass the card, whoever wears yellow/ blue/ red socks etc.
• How does Daily Standup relate to the Sprint Backlog - After the daily stand up, the team goes to the sprint backlog and updates the same [adds tasks/ edits tasks/ re-assigns tasks/ mentions work remaining etc]Who is the above reported to - Other team members
• Who is the above not reported to [in Daily Stand Up] - Customer, management, scrum master/ process coach/ agile coach or product owner
• What if the team looks at scrum master all the time - Daily stand up is a wonderful opportunity for the team to collaborate with each other and self organize. Hence, scrum master should turn around so that the team can talk to each other rather than them.
• Can Scrum Master question the team during daily Stand Up - No. The ideal place to do the same is “Sprint Review” meeting.
• What if someone has any questions - These can be taken up after the daily stand up
• What if team stands there like bozzos - Let them. Help them get out of their bozzo like existence long term rather than short term. Tell them they have 15 minutes to accomplish this as a team and see how they go about it. They would get better with time.

A daily stand up is perhaps the single most important ceremony in an Agile development framework. As discussed above, the purpose of a daily stand up is simple - “Meet for less than 15 minutes a day to inspect and adapt“. The team meets, synchronizes work, finds out how they should collaborate together, who needs help, who can help and are they on track or they need to re-organize to meet a sprint goal. The important thing here is “the team” does all this. The process coaches can help guide the team but not coerce or lead them to a particular way of thinking.

Although, the daily stand up is a wonderful tool for collaboration, it is also useful to highlight a lot of obstacles and things that are stopping the team from reaching excellence. As you can see one of the question team answers is “what is stopping us from doing our work“? Initially, the teams would make some politically nice statements. However, as the teams use of Agile intensifies, they will start revealing obstacles [we have to reach a QA through a project manager and that stops our work and focus, it would have been better to do a prototype first for this, customer is not available for feedback, these requirements are not clear, we do not have the skills to take on this work etc.]. Before you know there is a long list of obstacle backlog items that need to be addressed. This is where a Scrum Master or an Agile Coach or Process Coach comes into picture, whose main role is to “everything in his/ her power” to remove the obstacles and create conditions for the team to do their work in an enjoyable and optimal fashion. In fact one of the things good coaches should do is to get the team to raise as many obstacles as they can and beyond.

Popularity: 47%

Posted on February 17th, 2008 by admin
Filed under: Collaboration, Introduction, Practices | No Comments »