Scrum is an iterative and incremental agilesoftware development method for managing software projects and product or application development. Scrum enables the creation of self-organizing teams by encouraging co-location of all team members, and verbal communication between all team members and disciplines in the project. Three distinct roles are identified within the Scrum methodology:
The Scrum master, who ensures the process is followed, removes impediments, and protects the Development Team from disruption
The Product Owner, who represents the stakeholders and the business
The Development Team, a cross-functional, self-organizing team who do the actual analysis, design, implementation, testing, etc.
The development cycle of a software project is broken in to time boxed units which are called sprints. A common time frame for one sprint is one week. Every day within a sprint the progress of the project is evaluated.
Requirements of the final product are maintained in a list called the backlog (product backlog). In each sprint one or more requirements will be implemented (sprint backlog) after which the next sprint is started.
Scrum is facilitated by a Scrum Master, sometimes written as ScrumMaster, who is accountable for removing impediments to the ability of the team to deliver the sprint goal/deliverables. The Scrum Master is not the team leader, but acts as a buffer between the team and any distracting influences. The Scrum Master ensures that the Scrum process is used as intended. The Scrum Master is the enforcer of rules. A key part of the Scrum Master’s role is to protect the Development Team and keep it focused on the tasks at hand.
The Product Owner represents the voice of the customer and is accountable for ensuring that the team delivers value to the business. The Product Owner writes customer-centric items (typically user stories), prioritizes them, and adds them to the product backlog. Scrum teams should have one Product Owner, and while they may also be a member of the development team, it is recommended that this role not be combined with that of Scrum Master.
The Development Team is responsible for delivering potentially shippable product increments at the end of each Sprint. A Development Team is made up of people with cross-functional skills who do the actual work (analysis, design, develop, test, technical communication, document, etc.). The Development Team in Scrum is self-organizing.
A sprint is the basic unit of development in Scrum. Sprints last between one week and one month, and are a “time boxed” (i.e. restricted to a specific duration) effort of a constant length.
Each sprint is preceded by a planning meeting, where the tasks for the sprint are identified and an estimated commitment for the sprint goal is made, and followed by a review or retrospective meeting, where the progress is reviewed and lessons for the next sprint are identified.
During each sprint, the team creates finished portions of a product. The set of features that go into a sprint come from the product backlog, which is a prioritized list of requirements. Which backlog items go into the sprint is determined during the sprint planning meeting. During this meeting, the Product Owner informs the team of the items in the product backlog that he or she wants completed (the ones with the highest priority). The team then determines how much of this they can commit to complete during the next sprint, and records this in the sprint backlog. During a sprint, no one is allowed to change the sprint backlog, which means that the requirements are frozen for that sprint. Development is time boxed such that the sprint must end on time; if requirements are not completed for any reason they are left out and returned to the product backlog. After a sprint is completed, the team demonstrates how to use the software.
Scrum enables the creation of self-organizing teams by encouraging co-location of all team members, and verbal communication between all team members and disciplines in the project.
A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called requirements churn), and that unpredictable challenges cannot be easily addressed in a traditional predictive or planned manner. As such, Scrum adopts an empirical approach—accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team’s ability to deliver quickly and respond to emerging requirements.
Each day during the sprint, a project status meeting occurs. This is called a daily scrum, or the daily standup. This meeting has specific guidelines:
The meeting starts precisely on time.
All are welcome, but normally only the core roles speak
The meeting length is set (timeboxed) to 15 minutes
The meeting should happen at the same location and same time every day
During the meeting, each team member answers three questions:
What have you done since yesterday?
What are you planning to do today?
Any impediments/stumbling blocks?
It is the role of the Scrum Master to facilitate resolution of these impediments, although the resolution should occur outside the Daily Scrum itself to keep it as short as possible.
Sprint planning meeting
At the beginning of a sprint, a “Sprint planning meeting” is held.
Select what work is to be done
Prepare the Sprint Backlog that details the time it will take to do that work, with the entire team
Identify and communicate how much of the work is likely to be done during the current sprint
The team should spend time during a sprint doing backlog grooming. This is the process of: estimating the existing backlog using effort/points, refining the acceptance criteria for individual stories, and breaking larger stories into smaller stories.
Meetings should not be longer than an hour
Meeting does not include breaking stories into tasks
The team can decide how many meetings are needed per week.
Sprint review meeting
Review the work that was completed and not completed
Present the completed work to the stakeholders (a.k.a. “the demo”)
All team members reflect on the past sprint
Make continuous process improvements
Two main questions are asked in the sprint retrospective: What went well during the sprint? What could be improved in the next sprint?
Scrum of Scrums
Each day normally after the Daily Scrum.
These meetings allow clusters of teams to discuss their work, focusing especially on areas of overlap and integration.
A designated person from each team attends.
The agenda will be the same as the Daily Scrum, plus the following four questions:
What has your team done since we last met?
What will your team do before we meet again?
Is anything slowing your team down or getting in their way?
Are you about to put something in another team’s way?
Team Foundation System has integrated scrum support. With the Microsoft Visual Studio Scrum 1.0 template it is possible to maintain a product backlog, scope the sprints, define tasks, assign tasks and create several reports to monitor the progress of the sprint and the project.
The Scrum tools in TFS can either be accessed from Visual Studio or by using a web interface. The latter is useful for testers and project managers who do not have access to Visual Studio. Furthermore the web interface exposes some batch processing commands not available in Visual Studio.
Scrum is a suitable method to support development process. It is very efficient in creating solutions with the highest business value in the shortest possible time. Due to the daily scrums any impediments are known to everyone as they occur making it possible to resolves them as quickly as possible. Furthermore it adds support to prioritize work and closely monitor the progress of a project with little to no overhead.
Systems Development Life Cycle (SDLC) or Software Development Life Cycle is process of creating or altering the information systems which is used by people to develop these systems. It involves seven phases to complete this cycle. This process is often known as Waterfall model, a sequential process in which one activity is followed by another as shown in figure below:
The SDLC starts with the planning phase which illustrates the solid plan for developing the information system. The planning phase usually consists of mainly management tasks i.e. deciding and defining the information system which needs to developed, setting up the scope for the project and other project management tasks such as resource, task management etc.
Once the planning phase has been completed and it has been decided what needs to be developed, the SDLC moves to analysis phase. In this phase of the cycle, the business requirement are gathered which are required to be built into the information system. The requirement gathering is usually done by IT specialist in collaboration with end users. The requirements are also prioritised in this phase. One of the most important aspects of requirement gathering is that they should be as close to what user ‘really’ expects in the system. The confusion while gathering requirements often leads to bugs which translate to time, cost and effort in the later stages.
The design phase is where technical and solution architects sit together and come up with a system model and technical architecture for the information system. The goal of the phase is to have a proper and well thought design and architecture in place before moving to the development phase.
During the development phase, programmers from the development team take the blue print of the design and architecture documents. This is followed with the development of databases and programmes which are detailed in requirements specification done in analysis phase.
The testing phase of the life cycle verifies and validates the outcome of development phase i.e. the information system. Testing is important and is done by documenting and validating all the test cases and conditions. There are various types of testing done during this phase namely unit testing, system testing, integration testing and user acceptance testing.
This implementation phase of the SDLC is where the information system is made available to the end user. A detailed set of documentation is written which can help the user to get accustomed with the information system. Many large information system and organizations also set up other support procedures to help the end user and the setup of those processes also fall under implementation.
Maintaining the system is the final phase of any systems development effort. During them maintenance phase of the SDLC, you monitor and support the new system to ensure it continues to meet the business goals.
The SDLC or waterfall model takes a very singular approach to the information system development. It does not allow the development team to look around the software library and come up with generic pieces which can be reused. One of the disadvantages of this is every time the software needs to be written from beginning. This challenge has given birth to another approach which is called component based development.
In component based development, the focus is on developing small and reusable software components which can be used across multiple applications or information systems within the organization.
Rapid application development
In Rapid application development (or Rapid Prototyping) methodology, the emphasis is mostly on end user involvement during the development process. This is done by creating rapid prototypes to share with the end user and getting approval to speed up the development process. A typical RAD cycles looks like as shown below:
This end-user involvement and the use of prototyping tend to greatly accelerate the collecting of business requirements and the development of the software.
Prototyping is an excellent tool in systems development. Most often, IT specialists use prototyping in the SDLC to form a technical system blueprint. During the requirements determination portion of the systems analysis phase, system analysts gather information about the organization’s current procedures and business processes related the proposed information system. In addition, they study the current information system, if there is one, and conduct user interviews and collect documentation. This helps the analysts develop an initial set of system requirements.
Prototyping can augment this process because it converts these basic, yet sometimes intangible, specifications into a tangible but limited working model of the desired information system. The user feedback gained from developing a physical system that the users can touch and see facilitates an evaluative response that the analyst can employ to modify existing requirements as well as developing new ones.
The prototyping process involves the following phases:
Extreme Programming Methodology
The extreme programming (XP) methodology breaks a project into tiny phases and developers cannot continue on to the next phase until the current phase is complete. The primary difference between SDLC (waterfall model) and XP is that, XP divides the process into iterations. In conformity with RAD, XP as well depends a lot on development of components for the information systems.
The methodology takes its name from the idea that the beneficial elements of traditional software engineering practices are taken to “extreme” levels, on the theory that if some is good, more is better. It is unrelated to “cowboy coding“, which is more free-form and unplanned. It does not advocate “death march” work schedules, but instead working at a sustainable pace.
Agile is one form extreme programming methodology. Its main focus is on client satisfaction through continuous delivery. The focus of Agile is more on limiting the project scope than team coding in XP. An agile project sets a minimum number of requirements and turns them into a deliverable product.
Agile development methodology provides opportunities to assess the direction of a project throughout the development life cycle. By focusing on the repetition of abbreviated work cycles as well as the functional product they yield, agile methodology is described as “iterative” and “incremental”. In waterfall, development teams only have one chance to get each aspect of a project right.