A Simple Comparison of Scrum and XP
|
Scrum |
|
XP |
|
Sprint(1 month) |
|
Iteration(1-2 week(s)) |
|
Scrums |
|
Stand up |
|
PO |
|
On-site customer |
|
Product backlog |
Story card |
Release plan |
|
|
|
Continuous integration |
|
|
|
TDD (unit testing) |
|
|
|
Test first (functional testing) |
|
|
Retrospective |
|
|
|
Demo |
|
|
|
Both not have |
|
|
|
Requirements analyze |
|
|
|
Deployments |
|
|
|
Bug process |
|
Hi Binzy -
A few comments:
- Organizations do sprints from one week to one month in length. The most common I see is two weeks.
- We sometimes see on-site customers playing the product owner role, but sometimes that’s not realistic in which case we ask that a Product Owner who can speak for the customer, be available to the team.
- Scrum does include a product backlog and story cards but we don’t neglect release and product planning. Although Scrum in its most simple form may not include a lot of commentary on long-range planning, it can and often should be done, as long as it’s not to the exclusion of the incremental delivery of functionality.
- Scrum definitely has a component of requirements analysis, deployment planning and bug fixing. It’s a matter of lining up your management process and engineering processes.
Scrum is not an excuse for lack of regimentation, thinking ahead, or for bad engineering practices. By combining Scrum with the best practices from the Agile engineering world, I have seen teams excell and accomplish incredible feats. Please write anytime if you want to talk more!
Reply:
Hi Katie,
Really a surprise your comment is. Thanks a lot for your great comments.
- Yes, the length of scrum is not fixed. Actually in my team, we are always using the length of two weeks which is as you said.
- We do have a product owner who’s talking to customers, since we are distributed teams. (PO is in UK, we are in China, and our customers are all over the world.). So actually the members in our team are lack of experience to communicate with real customers but only talk to PO. In some respects, this is really good. But we still get the chance to misunderstand the requirements and can not feedback quickly.
- Agree with you. We always consider the sprint backlog as commitment which is almost like the release planning.
- Regarding those three aspects, I get this result mainly focus on the real components/definitions in Scrum and XP. From my experiences, I always meet difficulties when do these things.
○ [Requirements analysis]: We are using different Cards to record them and we do the analysis among the communications and conversations rather than the formal analysis documentations. That’s why I said scrum and XP don’t have the requirements analysis.
○ [Deployment]: Our products need a complicated deployment process, and always take so many time and the only thing we can do is waiting. We do use continuous integration. But there is not a clear definition in Scrum which is used for deployment. So we almost set up a separated team as a deployment team whose responsibilities is to deploy the qualified builds to production environment.
○ [Bug Fixing]: I do think Scrum and XP are assuming the bug should be fixed during the development or the bug is a totally different requirement. It’s different with some traditional methodologies which have defined some period for the bug process (fixing the bug after all rather than fixing right now). But the reality is we always get some bugs after we released the functionality. That really makes us out of our minds some time. So we added the TDD and Test First to our process to ensure the quality.
- BTW, I do think the Scrum is kind of management, when the XP is kind of development. So we are trying to use mix things.
Thanks for your comments again, it’s great to communicate with you. Look forward more conversation.
Thanks,
Bz
I would like to see a continuation of the topic
I will append something soon.
Hi guys,
we are developing our project using SCRUM. I would like to ask when the requirements are recorded? before the sprint or during the sprint?
thanks,
Özgür