04_Sprint Review Meeting - Facts & Rules

Source:  Agile Project Management with Scrum by Ken Schwaber

 

Duration:

 

1.             Time-boxed to 04 Hours (Four Hrs).

2.             Preparation Time Should not be more than 1 hour

 

Attendees:

 

3.             ScrumMaster should attempt to determine the number of people who expect to attend the Sprint review meeting and set up the meeting to accommodate them.

4.             Team members &  Stake Holders (Specially PO)  – Team  members  presenting functionality, answering Stakeholder questions.

 

Review Content:

 

5.             Functionality that isn’t “done” cannot be presented.

6.             Present to the Product Owner and stakeholders functionality that is “done”

7.             Although the meaning of “done” can vary from organization to organization, it usually means that the functionality is completely engineered and could be potentially shipped or implemented.

8.             Artifacts that aren’t functionality cannot be presented except when used in support of understanding the demonstrated functionality.

 

 

Review Procedure

 

9.             Sprint review starts with a Team member presenting the Sprint goal, the Product Backlog committed to, and the Product Backlog completed.

10.         Majority of the Sprint review is spent with Team members presenting functionality, answering stakeholder questions regarding the presentation, and noting changes that are desired.

11.         Stakeholders are free to voice any comments, observations, or criticisms regarding the increment of potentially shippable product functionality between presentations.

12.         At the end of the Sprint review, the Scrum Master announces the place and date of the next Sprint review to the Product Owner and all stakeholders.

 

 

Action Items – At The End

 

13.         At the end of the presentations, the stakeholders are polled, one by one, to get their impressions, any desired changes, and the priority of these changes.

14.         Stakeholders can identify functionality that wasn’t delivered or wasn’t delivered as expected and request that such functionality be placed in the Product Backlog for prioritization.

15.         Product Owner decides What is done and What is not.

16.         Product Owner & Team discuss remaining PB, determine what to do next and do prioritization.

17.         Different Team members can then discuss what went well and what didn’t go well in the Sprint.

 

 

Keep Blogging...

 

Regards,

Arun Manglick

05_Sprint Retrospective Meeting - Facts & Rules

Source:  Agile Project Management with Scrum by Ken Schwaber

 

Duration:

 

1.       Time-boxed to 03 Hours (Three Hrs).

2.       Occurs after Sprint Review & Before Next Sprint Planning meeting.

  

Attendees:

 

3.       Team, Scrum Master, and Product Owner.

4.       The Product Owner is optional

 

 Retrospective Procedure

 

5.       All Team members answer two questions:

a.       What went well during the last Sprint?

b.       What could be improved in the next Sprint?

 

6.       Also team members can think on four Short Subjects:

a.       Start Doing

b.       Stop Doing

c.        Do More

d.       Do Less

 

7.       The Scrum Master writes down the Team’s answers in summary form.

8.       Scrum Master does not provide answers, but facilitate the Team’s search for better ways for the Scrum process to work for it.

 

Action Items – At The End

 

9.       The Team prioritizes in which order it wants to talk about the potential improvements.

10.    Actionable items that can be added to the next Sprint should be devised as high-priority non-functional Product Backlog.

 

More Details On Retrospective

 

11.    Type of Retrospectives

a.       Iteration Retrospective

b.       Release Retrospective

c.        Project Retrospective

d.       Surprise Retrospective

 

12.    Retrospectives Improvements: Retrospective offers multiple improvements.

a.       Improved Productivity

b.       Improved Capability

c.        Improved Quality

d.       Improved Capacity

 

13.    Steps to Conduct Retrospectives

a.       Set the Stage

In this step, aim at creating an atmosphere where people feel comfortable speaking about things that may not have gone well on the project.

 

Few techniques:

·         Check-In

·         Focus On/Focus Off

·         ESVP - Explorers, Shoppers, Vacationers, Prisoners

·         Working Agreements

 

 

b.       Gather Data

Create a shared picture of what happened during the iteration.

 

Few techniques:

·         Timeline

·         Triple Nickels

·         Mad, Sad, Glad

·         Local Strength

·         Satisfaction Histograms

·         Team Radar

·         Like to Like

 

 

c.        Generate Insights

This step involves driving meaning insights from the gathered data in previous step and make sense out of it.

Activities done in this step help team interpret and understand implications of the issues before then move on to solving them.

 

Few techniques:

·         Brainstorming

·         Five Whys

·         Fishbone

·         Prioritize with Dots

·         Identify Themes

 

d.       Decide What To do

                        In this step, team will decide what they will change and how they will behave differently.

 

Few techniques:

·         Short Subjects - Start Doing, Stop Doing, Do More, Do Less

·         SMART Goals

·         Retrospective Planning Games

·         Circle Of Questions

 

 

e.       Close Retrospective

                        Here team summarizes:

·         What the team decided to keep

·         What to change

·         What we are thankful for

·         Where we can use our time going forward

·         Express Appreciation to each other

 

Few techniques:

·         Plus/Delta

·         Helped, Hindered, Hypothesis

·         ROTI (Return on Time Invested)

·         Appreciations

 

 

Keep Blogging...

 

Regards,

Arun Manglick

 

RE: Agile Estimation & Team Velocity

Here is an example of Agile Estimation & Team Velocity:

 

Assumption:

 

Resource Count: 8

Sprint - 4 Weeks (20 Days)

Team Velocity: 2000 Points

Per Sprint Per Resource Velocity: 250 Points

Productive Hours (Per Day): 6.5 Hrs

 

Story Sizes:

	Story Points	Days	Range (In Days)
Low	10	0.5	0.5-1 Day
Low-Medium	20	1.5	1-2 Days
Medium	30	2.5	2-3 Days
High	50	4.5	4-5 Days

 

 

Resource	Sprint Duration (4 weeks)	Velocity (Points)	Per Resource (Points) In 4 Weeks Sprint
8	20	2000	250

 

Below demonstrate kind of proper distribution of stories based on their point based estimate and days based estimate totaling to 2000 Points and 20 Days.

Well there is not necessarily directly proportional relation between story points and days.

 

However I tried demonstrating the same to justify Point Based & Days Based Estimation equally.

 

Estimate (In Days)	4.5	2.5	1.5	0.5	Days	Points (Per Resource)	Hours (6.5)
Estimate (In Points)	50	30	20	10
Resource 1	2	2	2	5	20	250	127
Resource 2	3	1	1	5	20	250	130
Resource 3	3	1	1	5	20	250	130
Resource 4	3	1	1	5	20	250	130
Resource 5	3	1	1	5	20	250	130
Resource 6	3	1	1	5	20	250	130
Resource 7	3	1	1	5	20	250	130
Resource 8	3	1	1	5	20	250	130
Total Stories	23	9	9	40	81	2000	1037
Total Points	1150	270	180	400	2000

 

 

Hope this helps.

 

Arun Manglick