Learn scrum in half an hour

Scrum is a project management methodology guided by 3 principles – transparency, inspection & adaption.

A cross-functional team delivers potentially shippable product increments in an iterative time-boxes called sprints. Inspect & adapt is a major theme in scrum which gives opportunities to improve in the current project itself. The Scrum methodology involves -

A. Scrum Roles

B. Time-boxes

C. Scrum Artifacts

D. Agile Rules

Scrum Roles

1. Scrum Master –

Scrum Master ensures that the team adheres to values, practices and rules of scrum. Scrum Master helps the team to perform it best in an organizational environment by tackling and resolving the impediments on day-to-day basis.

2. Product owner –

Production owner is the only person responsible for managing the product backlog and maintaining its prioritization. The product owner also ensures that product backlog is visible to everyone including the team and other stakeholders.

3. Team –

Team does the work. The team turns the product backlogs into increments of potentially shippable functionality every sprint after sprint.

Time boxes

1. Release Planning –

Release planning answers two question.

I. How a vision can be turned into a winning product in best possible way?

II. How the desired customer satisfaction and ROI can be met or exceed?

Release planning establishes the goal of the release, product backlog, major risks, and the overall feature and functionality that the release will contain. It also establishes the probable delivery date cost if nothing changes.

2. Sprint Planning –

Sprint planning has two parts.

I. What –

Input of this part of meeting is product backlog, the latest increment in the product, the capacity of the team, and past performance of the team. The team decides what functionality should be delivered based in the sprint based of these inputs.

II. How –

Team figures out how to turn the selected product backlog into an incremental “done”.

3. Sprint –

Sprint consists of sprint planning meeting, the development work, sprint review and sprint retrospective. Scrum Master ensures that no change is made that would affect the sprint goal.

Daily Scrum – A 15 minute meeting preferably standup to know –

I. What has been accomplished since last daily scrum meeting?

II. What is the plan for today?

III. What are the impediments?

4. Sprint review –

Sprint review meeting mainly reviews what has been done. Team demonstrates the work that is done and answers the questions. The product owner identifies what has been done and what hasn’t been done. The team discusses what went well and what problems they faced and how did they resolve them. The product owner discusses the product backlog. Sprint review meeting provides valuable input to the subsequent sprint planning meeting.

5. Sprint Retrospective –

Sprint retrospective reviews the last sprint in regards to people, relationship, process and tools like scrum team composition, meeting arrangements, definition of ‘done’, method of communication and processes for turning product backlog items into “done”.

Scrum artifacts

Product backlog, release burndown, sprint backlog and sprint burndown are the scrum artifacts.

1. Product backlog –

The requirement of product that the scrum team is developing are listed in product backlog. Product owner is responsible for creating, maintaining and prioritizing the product backlog.

2. Release burndown –

Release burndown is graphically records the remaining product backlog in terms of user story points or effort across the time.

3. Sprint backlog –

Sprint backlog is the list of the tasks the team commits to complete to turn the product backlog items into a ‘done’ increment. Items in sprint backlog should be decomposed enough to understand the changes in progress in daily scrum.

4. Sprint burndown –

Sprint burndown like release burndown is graphical display of sprint work remaining across the time in a sprint.

Sprint Rules

The 12 agile manifesto principals are the guidelines to make sprint rules.

Statement of work and Project charter

Statment of work - Statement of work is narrative description of product and service to be delivered by the project. This is the SOW’s definition by PMI’s PMBOK-IV.
A statement of work for an IT project should contain at least following information.
1. Purpose or goal of the project
2. Project scope
3. Deliverables
4. Cost and schedule information
5. Project success or acceptance criteria
6. Constraints
7. Assumptions
8. Management guidelines

Project Charter - Project charter documents business need, customer's requirements, new product, service or result and other project details as listed below.
1. Project purpose or justification
2. Measurable project objective or success criteria
3. High level requirements
4. High level project description
5. High level risks
6. Summary milestone schedule
7. Summary budget
8. List of stakeholders authorizing the project charter
9. Responsibility and authority level of project manager
10. Project approval requirements

The different between statement of work and project charter is statement of work is prepared by customer or sponsor and it’s used as input to create project charter. Project charter contains risks and project charter formal authorizes the execution of the project.

Use case point analysis - a software estimation technique

The number of use case points of a project is dependent on following factors.

1. The number and complexity of use cases in the application system.
2. The number and complexity of actors in the system.
3. Some non-functional attributes like portability, performance, scalability etc.
4. Environmental factors team’s experience and team motivation.

Complexity of a use case is defined as simple, average or complex depending on the number of transactions in the use case. Extension transaction which starts with result of another transaction shouldn’t be counted usually. Use case points are assigned to a use case based the complexity of the use case as listed in below table.

Unadjusted Use Case Weight
Use Case Complexity	No of Transaction	Weight
Simple	3 or fewer	5
Average	4-7	10
Complex	7 or more	15

Use case points for a use case actor are calculated per below summarized description in below table.

Unadjusted Actor Weight
Actor Type	Example	Weight
Simple	Another System Through API	1
Average	Another System through a protocol, a person through text-base user interface	2
Complex	A person through a graphical user interface	3

Total unadjusted use case point for a software project is calculated as summation of use case point and actor points as shown in below table.

Unadjusted Use Case Point
Sl No	Name	Use Case/Actor	Complexity	Number	Weight	Number*Weight
1	Use Case 1	Use Case	Average	2	10	20
2	Use Case 2	Use Case	Complex	3	15	45
3	Use Case 3	Use Case	Simple	6	5	30
4	Actor 1	Actor	Average	21	2	42
5	Actor 2	Actor	Complex	9	3	27
Total						164

There are 13 parameters in technical complexity with different weight value as listed in fig 4. These factors are assessed to a value between 0-5 depending on individual project requirement. The final technical complexity factor is calculated as TCF = 0.6 + (0.01 * TFactor).

Technical Complexity Factor
Factor	Weight	Assessment(0-5)	Impact
Distributed system	2	0	0
Performance objectives	2	1	2
End-user efficiency	1	3	3
Complex processing	1	4	4
Reusable code	1	4	4
Easy to install	0.5	1	0.5
Easy to use	0.5	1	0.5
Portable	2	4	8
Easy to change	1	5	5
Concurrent use	1	5	5
Security	1	5	5
Access for 3rd party	1	5	5
Training Needs	1	1	1
Total (TFacor)			43

There are 8 parameters in environment complexity with different weight value as listed in fig 5. These factors are assessed to a value between 0-5 depending on the environment in which project is executed. The final environment factor is calculated as EF = 1.4 + (-0.03 * EFactor).

Environment Factor
Factor	Weight	Assessment(0-5)	Impact
Familiar with the development process	1.5	1	1.5
Application experience	0.5	3	1.5
Object-oriented experience	1	2	2
Lead analyst capability	0.5	5	2.5
Motivation	1	2	2
Stable requirements	2	1	2
Part-time staff	-1	1	-1
Difficult programming language	-1	3	-3
Total (EFacor)			7.5

And, finally total use case point of a software project is UUCW*TCF*EF where UUCW is unadjusted use case weight, TCF technical complexity factor and EF is environment factor.

Functional point analysis - A software estimation technique

Functional point is a standard unit of measure that represents functional size of a software application. Functional point analysis quantifies the functionality of a software application from user perspective based on a logical design. It’s technology independent and consistent across the project and across the organization.

There are five standard functions divided into two categories in functional point analysis as named below.

1. Data Function: There are two type of data functions - Internal logical file (ILF) & External interface file (EIF)

a. Internal logical file (ILF) – ILF is a group of data which are logical and user identifiable. Data defined by ILF is maintained through the elementary process occurring within the boundary of application whose functions are being counted.

b. External interface file (EIF) – EIF is also a group of data which are logical and user identifiable just like ILF. Here, the difference is EIF data is maintained outside the boundary of application whose functions are being counted. Based on the count of data element type (DET) and record element type (RET), low, average and high complexity is assigned to a data function - ILF or EIF and based on complexity of an ILF or EIF, function points are assigned to it as per below table.

c. Data element type (DET) – DET is a user recognizable and non-repeatable data of a data function – ILF or EIF.

d. Record element type (RET) – RET is user identifiable subgroup of DETs and it is part or subset of a data function - ILF or EIF.

Data Functions (ILF, EIF)
RETs	DETs				Functional Point
	1-19	20-50	51-51+		Complexity	ILF FP	EIF FP
1	L	L	A		L	7	5
1-5	L	A	H		A	10	7
6-6+	A	H	H		H	15	10

2. Transaction Function There are 3 types of transaction functions - External input (EI),External output (EO) & External inquiry (EQ).

a. External input (EI) – EI is a data entered by the user or data/file fed by an external application.

b. External output (EO) – EO is a report created by the application in consideration where the report contains derived information/data.

c. External inquiry (EQ) – EQ is a report created by the application in consideration where the report doesn’t contain the derived info/data. Based on the count of data element type (DET) and file transaction reference (FTR), low, average and high complexity is assigned to a transaction function - EI, EO or EQ and based on complexity of an EI, EO or EQ, function points are assigned to it as per below table.

d. File Transaction reference (FTR) – A FTR is an either ILF or EIF referenced by the transaction function of the application whose functions are being counted.

Transaction Functions (ILF, EIF)
FTR(EI)	DTE				FTR(EO, EQ)	DET
	1-4	5-15	16+			1-5	6-19	20+
0-1	L	L	A		0-1	L	L	A
2	L	A	H		2-3	L	A	H
2+	A	H	H		3+	A	H	H
Functional Points
Complexity			EO FP		EQ FP		EI FP
L			4		3		3
A			5		4		4
H			7		6		6

Count of data functions and transaction functions will give the total unadjusted function point count which can be put as in below table

Sl No.	File/Trans Name	Function Type(Data/Trans.)	Fn Type Name (ILF,EIF,EI,EO,EQ)	DET	RET	FTR	Complexity	Function Point
Total Unadjusted Function Point

There are also some other factors which influence the functional size of a software application. It's called value adjustment factor as a group. There are 14 parameters in the value adjustment factor known as general system characteristics listed as in below table.

General System Characteristics(GSC)	Weight(0-5)
Data Communication
Distributed data processing
Performance
Heavily Used Configuration
Transaction Rate
Online data entry
End user efficiency
Online update
Complex processing
Reusability
Installation ease
Operational ease
Multiple sites
Facilitate change
Total Degree of Influence
Variable Adjustment Factor

These characteristics are given weight value of 0-5. Value adjustment factor is calculated as VAF = (TDI * 0.01) + 0.65

And, final function point count of a software application is derived as UFPC*VAF where UFPC is unadjusted function point count and VAF is value adjustment factor.