Steps - Product Owner starts by explaining a user story to team Story can be further divided at granular level task (Action Items) Story can have multiple tasks These task would be estimated for efforts required to develop each Every team member can write his estimated Story Point on a Card Play card are collectively displayed to everyone For example 1,2,4,6,6,4,8,8,12 are the cards shown by a team Outliers can be picked up first for analysis Like 1 and 12 would be analyzed first in above example Developer/team will provide prospective and insight for tagging them 1 and 12 And this discussion can address more insight over what exactly is to be developed Estimate can be done on teams agreement on a number. As a practice team can pick an estimate for general understanding .
Held daily 15- Minutes (no longer, otherwise it’s not a daily stand up) Not for problem solving (if there are issues that need to be addressed hold a separate meeting) Is not a status for the scrum master or project owner. It’s commitments in front of peers Fix Place – Hold the daily scrum in the same place at the same time every work day. Time – Best time is early in the morning so that the first thing team members do on arriving at work is think of- What they did the day before? and, What they plan to do today? All team members are required to attend. Cannot attend in person, by phone or by having another team member report on the absent members status. Team members must be prompt. The scrum master starts the meeting at the appointed time, regardless of who is present. Each team member should respond to three questions only: 1. What have you done since the last daily scrum regarding this project? 2. What will you do between now and the next daily scrum meeting regarding this project? 3. What impedes you from performing your work as effectively as possible?
Focus on acceptance criteria . You’ve defined what done means for the story (right?), so focus your demo around proving that you’re actually done. Start with the demo in mind . Don’t wait to think about the demo until you’re done with the story. You might be able to write tests that double as demo scripts. And it’s best to plan your demo for a story while it’s fresh in your mind, before you move to the next story. Prepare . Don’t ad lib. Think through an interesting scenario to prove that you’ve satisfied the core acceptance criteria. Create any necessary test data. Use tools like Selenium if necessary to get your app into a state where you can start an interesting demo. Practice . Run through the demo at least once. When you’re getting started, you might want to grab a trial version of Snagit and record yourself giving the practice demo. Painful, huh? That just means you need to work on it. Tell a story . Center your demo around a realistic user solving a real problem. The point is not just to show that the software works, but to show that it’s valuable. Keep it short . If you work on your stories one at a time and get them accepted when they’re ready, you don’t need to exhaustively cover all your acceptance criteria in your demo. Instead, focus your demo on what’s interesting and what’s valuable about each feature.
Velocity can be calculated by Using historical data Running an iteration Making a forecast Example: In last iteration team completed 3 user stories (where Story 1 is having 5 story points, Story 2 had 4 and Story 3 had 2) then Velocity is 5+4+2 = 11 Story Points. Iteration can be planned using velocity. Release planning is based on Velocity
Individual stories are presented for estimation. After a period of discussion, each participant chooses the numbered card that represents his estimate of how much work is involved in the story under discussion. All estimates are kept private until each participant has chosen a card. At that time, all estimates are revealed and discussion can begin again .
Product Owner starts by explaining a user story to team
Every team member thinks/writes about his estimated Story Point for that story.
Estimated are collectively displayed to everyone
For example 1,2,4,6,6,4,8,8,12 are the cards/estimates shown by a team
Outliers can be picked up first for analysis
Like 1 and 12 would be analyzed first in above example
Developer/team will provide prospective and insight for tagging them 1 and 12
And this discussion can address more insight over what exactly is to be developed
Estimate can be done on teams agreement on a number.
As a practice team can pick an estimate for general understanding.
Rules : Don’t go to details & Park the question for later sprints , Time Box,
Planning Poker cont Clarity ? Tester Coder UI Dev Tester Coder Coder 4 8 3 2 4 1 User Story Planning Poker Outliers Discussion Estimates