Main Differences Between Agile Scrum And XP Framework
Tue 11 Nov 2014 00:07
"There are subtle, but marked, differences between Agile scrum and XP frameworks. While both the frameworks appear to be similar at a first glance, the differences lie in how the sprint backlog items are committed, and how the development team takes up the user stories for development during the daily sprints."
Of all Agile frameworks, scrum is the most popular one. Scrum methodology is highly recommended for developing IT projects and it is so widely recommended for it that it is often confused with Extreme Programming or "XP" Agile framework, which is synonymous with software development. Both the frameworks are much similar, and to a person not conversant with Agile, both might appear to be the same at a first glance. While most Agile processes and events remain the same, there are some subtle differences between the two frameworks.
Typically, in scrum, the sprint iteration can last from two weeks up to one month. In XP, the duration is much shorter, and generally lasts from one to two weeks. The sprint duration does not exceed two weeks in XP.
Committing the sprint backlog
One of the major differences, and an important one too, is how user stories are committed in the sprint backlog while implementing scrum and XP. In scrum, the sprint backlog is "owned" by the development team. Once the team accepts the sprint backlog, all the user stories in the backlog are "committed" for development purposes. The team is required to complete all the user stories stated in the backlog. Moreover, once committed, the sprint backlog cannot be "changed" while implementing scrum. If any new user story is required to be developed, it can only be included in the next sprint after a new sprint planning meeting is conducted. This is not the case with XP. The sprint backlog does not become "static" even after it is accepted by the team and the user stories are taken up for development. If required, based upon the feedback received from the stakeholders, a user story taken up for development can be replaced with another one having the same estimation in terms of story points. Therefore, the sprint backlog is not "committed" at any time in XP. New stories can be replaced in lieu of those currently existing in the backlog - something that is impossible in scrum. However, it is important to know that such a "replacement" of user story is only possible in XP before the particular user story is taken up for execution in the daily sprint. Once the development of a user story starts in XP, it cannot be replaced.
Determining the sequence while developing user stories
The role of the product owner remains common in both scrum and XP. The PO prioritizes the product backlog in accordance to the importance of user stories based upon the business values. Feedback is availed from the stakeholders as to which of the user stories are more important and pertinent from the development point of view, and the PO categorizes the product backlog based upon the business values of the user stories. The similarity, however, ends there. In scrum once the user stories are prioritized and taken up for development during the daily sprints, the development team enjoys the autonomy of deciding how the user stories should be actually taken up for development during the daily sprints. The team can decide the order, or the sequence, in which it desires to develop the user stories. This does not occur in XP framework. The development team in XP has to strictly adhere to the priority of the user stories as decided by the PO and carry out the development in the same order of priority. In XP, the team cannot choose the order in which the user stories should be developed. It is decided beforehand by the PO or the client. The team is required to stringently follow the priority as stated in the sprint backlog. In scrum framework, it is highly common for the team to start with the second-most-important user stories rather than the most important ones during the daily sprints. Larger user stories or "epics" are generally developed subsequently since they consume more development time. This is generally done to maintain the velocity during the scrum process , which is depicted in the burn down charts. It is important for the team to remain close to the "ideal" line so that the velocity is maintained at all times. Taking up easier user stories generally helps the team to remain consistent with the projected velocity. This is not possible to do in XP.