The document discusses Scrum practices used by a Chengdu team. It describes how the team uses Scrumworks Pro to host sprint backlogs and deliver test cases to the Product Owner as a Definition of Done. It also discusses how the team conducts testing and releases engineering builds after each code check-in to allow features to be released quickly. The document outlines conventions for an integration Scrum team and how common test suites are formed across multiple teams.

1. Scrum Practices Linchuan Wang Scrum Assembling in Chengdu May 23, 2009

2. Scrum Dash Board of Chengdu Team Two

3. Sprint Backlog We’ve tried out Scrumworks Pro to host all backlogs.

4. DoD 3 A sheet of test cases (generated from Testlink server) will be delivered to the Product Owner as early as possible as a DoD. If the PO has any comments he will let the team know immediately. This set of test cases also is being used to drive daily development (each case created and owned by a pair of developer and tester). The pair of developer and tester will work on these test cases in the whole Sprint. So, we’re actually DoD 3 (DoD Driving Development)  Test Case Team Product Owner DoD TDD

5. Test Report for Sprints As a part of DoD, a test report (refer to the next page ) will be released along with the running software. The PO will check the software against it even remotely. (we do not have the PO locally in most demo meeting so this is especially important) As usual, the PO will find a little number of new defects not covering by these test cases (DoD) which will be fixed in the next Sprint. And the team learned to make better test cases (DoD). No team could deliver bug-free software. In that sense, the pass rate would not be 100%. So an agreement on the mandatory test case set should be reached between the PO and the team in the beginning of the Sprint if necessary .

6. Scrum of Scrum with the Integration Team Team One Plenware Team Two Plenware XYZ Team US Team Team ABC HW Team Artist Team Integration Team Customer Release&test report Customer Defects report Release Notes -new features -known bugs&limitations -change logs … Component/Feature Test Case and Report Smoke Test Case Report Bug and defect report Engineering Release Since the main repo is keep up updated (and built) continually , for each check-in there would be one build, so the customer (whoever) could get any check-in build as an “as-is” engineering release. In that sense, every one (team) can release a new feature, patch or whatsoever by pass the integration team for convenience without quality assurance if that’s really somebody wants. !!!NOTE!!! For each single check-in on the main repo the submitter HAS to make sure the smoke test case could be passed. If it’s not sure please execute the smoke test by yourself. Smoke Test Case

7. Convention of Integration Scrum Team Integration teams mainly focus on build, test, release … instead of actual development. It can share team member with development Scrum teams. All updates should get confirms from this team before spread it out All release should be delivered by this team All updates and check-ins from task teams must have test cases along with test status (report) The defects found by this team often have high priority

8. How to form Common Test Case Suite Team One Plenware Team Two Plenware XYZ Team U.S. Team ABC HW Team Artist Team Integration Team Test Case Test Case Test Case Test Case Test Case Test Case Common Test Case

9. How it works All test case of Set 1 passed Action: request a regression test Red Team Blue Team Integration Team Working Log Test Case Set 1 Test Case Set 1 Test Case Set 2 Test Case Set 3 Test Case Set 2 A Sprint Regression testing trigger Some test case of Set 1 passed Action: Check in regression one Blue team has to pass three sets of test case to meet the Sprint Goals. Red team has two. Integration Team has to pass 5 sets from both Red and Blue Team plus all sets passed previously for new deliverable by the end of Sprint. Main repository Start regression testing Action: test case execution Defects Reporting Check-in Test Case Set 1 Test Case Set 1 Test Case Set 1 Test Case Set 1 Test Case Set 2 regression two … Smoke Test Smoke Test Smoke Test Smoke Test Smoke Test Smoke Test: For each single check-in on the main repo the submitter HAS to make sure the smoke test case could be passed. If it’s not sure please execute the smoke test by yourself. Smoke Test

10. Release Planning

11. Team One

12. Team One Cont’ 195hrs left 42pts planned 29pts_burned.

13. Team Two

14. Team Two Cont’ 23hrs left 28pts planned 27pts_burned

15. Team Three 170hrs left 71pts planned 54pts burned.

16. Enhanced Product Burdown

17. Completion Forecasting

18. Project Management Retrospective

19. “ You must unlearn what you have learned. “

20. Work the Manager used to do that the team now does: 1. Make commitments on behalf of the team about how much they can get done by a certain date 2. Convince team that the commitments made on their behalf are attainable 3. Give direction to the team on how to implement the work, so they can deliver on the commitment 4. Monitor the team's progress, to make sure they stay on schedule, and isn’t having problems 5. Step in and determine the solution, if the team falls behind on their schedule, or starts having problems 6. Conduct weekly status update and 1:1 meetings with the team, to surface issues, and provide direction 7. Provide motivation and push the team to work harder than they might want to, using carrots and / or sticks 8. Decide task assignments among the team members and follow up on tasks to make sure they've been done 9. Be responsible for the team doing the right thing at the right time in the right way.

21. Basic truths about team motivation 1. People are most productive when they manage themselves; 2. People take their commitment more seriously than other people’s commitment for them; 3. People have many creative moments during down time; 4. People always do the best they can; and, 5. Under pressure to “work harder,” developers automatically and increasingly reduce quality.

22. Basic truths about team performance 1. Teams and people do their best work when they aren’t interrupted; 2. Teams improve most when they solve their own problems; and, 3. Broad-band, fact-to-face communications is the most productive way for teams to work together.

23. Basic truths about team composition 1. Teams are more productive than the same number of individuals; 2. The optimum size team is around seven people, and no more than nine; 3. Products are more robust when a team has all of the cross-functional skills focused on the work; 4. Changes in team composition ruin productivity.

24. “ Luke… Let go. Trust the force.”