What is scrum ?
Scrum is a subset of agile methodology which is a lightweight process framework for agile development. It is the most widely used framework used for agile development. A process framework is a particular set of practices that must be followed in order for a process to be consistent with the framework. For example, the scrum process framework requires the use of development cycles called sprints, the XP framework requires pair programming, and so forth. “Lightweight” means that the overhead of the process is kept as small as possible to maximize the amount of productive time available for getting useful work done.
What is scrum used for ?
A scrum process is distinguished from other agile processes by specific concepts and practices, divided into the three categories of Roles, Artifacts, and Time Boxes. Scrum is most often used to manage complex software and product development, using iterative and incremental practices. Scrum significantly increases productivity and reduces time to benefits relative to classic waterfall processes. Scrum processes enable organizations to adjust smoothly to rapidly-changing requirements, and produce a product that meets evolving business goals.
How does scrum help the organisation ?
An agile scrum process benefits the organization by helping it to :
1. Increase the quality of the deliverables
2. Cope better with change and expect the changes
3. Provide better estimates while spending less time creating them
4. Be more in control of the project schedule and state
What are the scrum requirements ?
Scrum does not define just what form requirements are to take, but simply says that they are gathered into the Product Backlog, and referred to generically as product backlog items or PBIs for short. Given the time-boxed nature of a Sprint, we can also infer that each set should require significantly less time to implement than the duration of the Sprint. Most Scrum projects borrow the XP (Extreme Programming) practice of describing a feature request as a user story, although a minority uses the older concept of a use case. We will go with the majority view here, and describe three reasonably standard requirements artifacts found in product backlogs.
What is a user story ?
A user story describes a desired feature (functional requirement) in narrative form. User stories are usually written by the Product Owner, and are the product owner’s responsibility. The format is not standardized, but typically has a name, some descriptive text, references to external documents such as screen shots and information about how the implementation will be tested. Not all requirements for new development represent user facing features but do represent significant work that must be done. These requirements often represent work that must be done to support user facing features. We call these non-functional requirements “Technical stories.” Technical stories have the same elements as user stories, but need not be cast into narrative form if there is no benefit in doing so. Technical stories are usually written by team members, and are added to the product backlog. The product owner must be familiar with these stories, and understand the dependencies between these and user stories in order to rank all stories for implementation.
What is a defect ?
A defect or bug report, is a description of a failure of the product to behave in the expected fashion. Defects are stored in a bug tracking system, which may or may not be physically the same system used to store the product backlog. If not, then the product owner must enter each defect into the product backlog for sequencing and scheduling.
