What is Software Development ?
Software Development is the process of developing a Software Product or execution of a Software Project.
A software designed to satisfy a specific segment of the market requirement is called a Software Product. For example, ‘Hospital Information System’ is a software product to meet the administrative and clinical requirements of a Hospital.
A project where service(s) is offered to meet specific requirements of a customer is called Software Project. For example, Implementation of ICD-10 changes on the customer IT systems.
Software Development Life Cycle (SDLC)
Two most widely used SDLC process which majority of the Product Development Organizations follow are Waterfall and Agile methodologies. Waterfall model follows a sequential approach and is process oriented whereas Agile model follows an incremental approach and is people oriented. It is difficult to say which model is better. Selection of Agile or Waterfall Model depends on three important factors i.e. project contract (Fixed Price/Time & Material), requirements (unambiguous/ambiguous) and the customer delivery needs.
There are number of specific methods under Agile Model. Scrum is one of the widely used Product Development Methodologies which uses Agile Framework. It is an iterative SDLC process to manage projects and product development.
Let us understand Scrum Methodology with an example:
Project Requirement: There is a requirement to create ‘Outpatient Registration’ application which should support the following features:
- New Outpatient Registration
- Collect Registration Amount
- Print Registration Card
- Print Registration Amount Receipt
- Modify Outpatient Registration Data
- Record Patient Revisit to the Hospital
- View Outpatient Registration Data
- Cancel Outpatient Registration
Team consisting of the following members is formed to start the project.
Scrum Phases and Process
Scrum is a time boxed development process which has fixed length iterations called Sprint which typically lasts typically for 2 to 4 weeks. Each Sprint has distinct phases as shown in the figure below:
Note: Scrum Team comprises of 5 to 7 members and all the members have equal skill sets.
Product Owner creates Product Backlog Items (PBI) with inputs from customer/market requirements and product roadmap. Each item in the product backlog is explained in the form of User Stories. High priority requirements are considered first followed by low priority items. PBIs are prioritized based on Business Value, Dependency and Risk Factor.
- Scrum doesn’t define any structured method to define Product Backlog Item. Some of the techniques from eXtreme Programming (one of the Agile Methodologies) like User Story, Epic, Theme are used to define Product Backlog Items.
- PBI list can contain features, bug fixes and enhancements.
- User Story is requirement told as a story by the customer. User Story typically should say who the user is, what is the task that the user wants to perform, value that can be derived out from the task.
- Theme is a collection of user stories; Epic is a big user story which needs to be split into smaller user stories. Theme can have multiple epics; each Epic can have multiple small user stories; each User Story can have multiple tasks.
Product Owner completes writing user stories for the high priority requirements:
Note: Product Owner has completed User Stories for 3 high priority requirements. Status will be updated accordingly to In Progress (Started), Done (if the completed solution meets the acceptance criteria) during the course of the project.
Product Owner also prepares the Release Plan in consultation with the Stakeholders:
Table 1: Release Plan
|Feature||Release 1||Release 2|
|Outpatient Registration||1. New Outpatient Registration
2. Print Registration Card
3. Collect Registration Amount
4. Print Registration Receipt
|1. View Outpatient Registration data
2. Record Patient Revisit
3. Modify Registration Data
4. Cancel Registration
Sprint Planning Meeting
Product Owner explains the high priority items in the product backlog to the scrum team to the extent that they can break the user stories into detailed tasks.
Note: It is not required for the Product Owner to explain all the user stories during sprint planning meeting. User Stories sufficient for minimum of two sprints should be explained.
Based on the sprint planning meeting, scrum team selects four user stories 1001, 1002, 1003, 1004 to be executed in the first sprint and moves it to sprint backlog for defining tasks. Sprint duration is planned for 2 weeks. Sprint goal is also defined.
Note: It is final decision of the development team to decide the number of top priority PBI to be included in a Sprint and Product Owner does not have any say in this. Also, the low priority PBI will be considered on completion of top priority items.
Sprint Goal: Develop New Outpatient Registration with features to register new patient and print registration card.
Scrum Team prepares Sprint Backlog and updates it at the end of each day:
Table 2: Sprint Backlog
Note: User Story defines ‘what is the requirement’ and Task defines ‘how the requirement will be achieved’. Task is the smallest level of work break down structure.
Daily Scrum Meeting
Scrum Master facilitates daily scrum meeting for 15 minutes to understand the project progress and issues (if any) from the scrum team. During this meeting, one of the members’ X informed that he is finding it difficult to implement task 6. Team member Y informed that she can take up task 6. Hence, task 7 is assigned to X and task 6 to Y. In this way, rotation of work happens incase someone is finding it difficult to handle a task.
During another daily scrum meeting, the team informs the scrum master that user story 2 is taking lot of time and the estimates are going more than the original (from 24 hrs to 36 hrs). Product Owner is brought in for a discussion by the scrum master.
Product Owner removes user story 2 and modifies user story 3 (as User Story 3 is dependent on User Story 2). Estimate of user story 3 remained same as original i.e. 24 hrs. After this modification, project continued smoothly.
Scrum Master prepares Sprint Burndown Chart based on the number of hours of work remaining at the end of each day:
Sprint Review Meeting
Scrum Team presents the work i.e. User Stories 1001, 1003, 1004 in the form of a demo to the Product Owner, Stakeholders (Management, Customers). Solution is accepted by everyone. However, per the release plan prepared by the product owner, release 1 should have user stories 1001, 1003, 1004, 1005. In addition to this, release 1 should also include Print Registration Amount Receipt which is not completed. Hence, the release will not be done to the Customer.
Note: If all the requirements under release 1 was included & completed in this sprint, then the team could have released the code to the customer for user acceptance. On passing user acceptance, the code is deployed on the customer production environment.
Sprint Retrospective Meeting
Scrum Team, Scrum Master and the Product Owner meet to discuss the following points on the past sprint:
- Things that went wrong
- Things that went right
- Things that need improvements/changes
Product Backlog Refinement
To ensure that the product backlog is ready for the next sprint and based on the feedback from sprint review and sprint retrospective meetings, product owner:
- Splits big user stories into smaller ones (Ex: User story related to ‘Collect Registration Amount’ broken down into ‘Collect Registration Amount with single payment mode’ and ‘Collect Registration Amount with multiple payment modes’)
- Removes user stories that are not relevant (Ex: User Story related to ‘Record Patient Revisit to the Hospital’ removed)
- Re-assesses the priority of user stories (Ex: Priority of the user story related to ‘Modify Outpatient Data’ changed to medium from low)
- Includes enhancements as new user stories (Ex – Option to clear the data on the ‘New Patient Registration’ page)
- For the above, the assumption is the product owner has completed writing user stories for the remaining requirements.
- Bugs if any reported can also be included as user stories in the product backlog as part of product backlog refinement. (Ex: ‘Date of Visit’ not defaulting to the current date)
- Release Plan also need to be modified accordingly based on the feedback of product backlog refinement meeting.
Scrum follows 3Ds i.e. Divide, Develop and Deliver policy for development of software product. Use Scrum when:
- Final product is not clear
- Changes to the requirements are anticipated
- Need for rapid deployment of the product
- Less inter-dependencies of the features
- Custom Software Development
Use Waterfall Model when:
- Requirements are clear and fixed
- Project is fixed price contract
- Experience in working on similar projects
- Project is simple
- Speed is not the key to success
- Multiple software components need to be designed in parallel for integration with external systems (Because the design is completed early in the development lifecycle).
Whether it is Waterfall, Agile, Lean, Rational Unified Process or any other SDLC process, each process has its pros and cons. Depending on the project needs, Service Provider Organisation has to select the SDLC process that meets their, and the customer objectives and goals.