Scrum with XP (eXtreme Programming) Style
From my perspective, Scrum is a methodology of management and it’s quite loose, but the XP is a methodology of development and it’s quite specific. So Scrum is like a framework, you could develop your concrete process. In Scrum, the approach you apply in the development is quite free. It depends on your team’s ability and tradition. So naturally, we will consider bringing some stuffs from XP into Scrum.
1. Split Sprint into small iteration
Normally, 1 sprint is 1 month within same length. But sometime, it’s still too long to control and commit. So we could split it into small iterations, like 1 week per iteration. But we still will have the Sprint planning meeting to pick up and definite the scopes of next sprint, then separate the sprint backlog items into iterations according to the priority. Meanwhile the iteration planning meeting will happen in every beginning of iteration. With small iteration, it’s easy to get the velocity more accurately.
2. User story and Spike in planning
Since the product/sprint backlog could be very simple, no information very detailed and deep, it’s difficult to estimate them sometime, especially when you are not sitting together with customers/users. So a good user story would be really helpful to understand the requirement and to estimate it. The communication is still needed, certainly.
The commitment is the target of the team, so it’s tough to estimate features when we get uncertain things within it. The spike supplies the practice guidance of this situation. We could do a spike before estimate the real work and to produce the possible solutions to PO. Then we could give the correct estimation when PO confirms the solution.
3. TDD and Refactory
No methodology guideline for how to code and test in Scrum. So normally we will apply TDD and Refactory into the development. Modern IDEs (Visual Studio for .Net, Eclipse for Java, Zend for PHP …) all provide these two functions.
4. Pair Programming
It’s difficult to involve Pair Working into scrum (I will detail this in following entry). But Pair programming is the best way to share knowledge and assure the quality.
5. Continuous Integration & BVT
CI could help us to find questions at the very beginning. BVT could ensure the major functionalities of the product won’t be broken. (Cruise Control is a good tool.)
6. Acceptance Tests
Acceptance is the guideline of the test cases. We also could create automation tests base on acceptance criteria.
7. Combined style of daily scrum and daily stand-up
In daily Scrum, team members will focus on 3 questions:
a. What I’ve done from last daily Scrum
b. What I will do in next
c. Any obstacles
Via these 3 questions, we could easily know the status. But it’s hard to know other team members’ ideas or comments. So we could plus another question:
d. Any feedbacks?
Although we plus this, we still need to focus and control the meeting time. If the feedback would be long, it should be discussed after the daily scrum.
