1. Software Development Process-Scrum 1
System Analysis & Design Course
Sharif University of Technology
MohammadAmin Fazli

2. Process
A process is a sequence of activities that builds on one another to achieve a result.
Understanding the basics of processes is important to know which aspects can be influenced.
Such knowledge helps making the right choices to improve the way of working.
We should aim to automate optimized processes only.

3. Decision Making Level Goal Result … Operational Level 1st Step
Measures, Controls, Responsibilities, Roles
Goal
Result
Customer
1st Step
2nd Step
Nth Step
Transformation
Input
Output …
Materials, Machines,
Labour, Information
Information, Service, Goods
Operational Level

4. Agile
Agile is a time-boxed and iterative approach of software delivery.
It aims to build software incrementally from the start of the project.
Agile focuses on smaller functional units instead of developing the complete software in a go.

5. Agile
The Agile way of working breaks a product into functional units according to user stories and prioritizes them to continuously deliver software in short cycles known as iterations.
It is often used as a time-boxed, iterative approach to software delivery. It is aimed for building and delivering software incrementally throughout the project instead of trying to deliver the complete product at or near the project end.
The Agile way of working largely incorporates feedback loops to help teams to respond to the ever-changing outside world.

6. Agile
When features get delivered by an Agile team, these are in a state of ‘done’.
The Definition of Done (DoD) describes when a feature is done. In other words, the feature is developed, built, tested, and approved. In addition, it is running in production.
The Agile way of working strives towards finalizing a complete task first, before starting with a new one.

7. What is the difference?
The key difference is the delivery of a useful product from the first iteration in the Agile way of working.

8. In Traditional
Large upfront planning (in an ever changing environment)
No value is returned to your investor until the end.
Investments are based upon hypothesis.
Has deadline, but no feedback from the customer/team.

9. But in Agile Agile is about using feedback
Feedback related to the product, team velocity, budget, situation in the market, or even the situation in the world.
The feedback allows the team to swiftly react.
The product is ‘shaped’ along the way, using feedback from the end-user.

10. Plan Driven
The traditional plan-driven sets a fixed functionality and a level of quality.
The level of quality (the non-functional requirements) is often not even articulated at that stage.
Once the required amount of resources and time is estimated, the project starts.

11. Problem
Sizing (setting resources and time) has to be estimated at the start of the project!
Once the deadline passes by, it becomes clear that the guess was too optimistic.
The pressure starts to build on the team, often resulting in loss of quality, functionality, or both.
Customers will become unhappy.

12. Value Driven
The value-driven is about knowing the available number of resources and amount of time.These parts are more or less fixed.
Deliverable functionality is calculated by resources.
Not done for the complete project, the estimation is only for the Sprint at hand.
Customers become happy.
valuable feedback from customers can be incorporated in every sprint.

13. Principles of Agile Manifesto
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

14. Principles of Agile Manifesto
people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to- face conversation.

15. Principles of Agile Manifesto
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.

16. Principles of Agile Manifesto
Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Source:

17. The Agile Manifesto
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
“That is, while there is value in the items on the right, we value the items on the left more”
Source:
Translation:

18. Roles 3x
Customer
Team
Scrum
Master
Product
Owner

19. Scrum Roles: Team
Consists of members having the skills to define, develop, test, deploy, maintain, and communicate the various aspects of the product.
A typical Scrum team is about 5-9 members in size.

20. Scrum Roles: Scrum Master
The person responsible for making sure the team adhere to Scrum behaviors, rules, and guidelines.
He/she is the facilitator who ensures everybody plays by the rules.
Not only explains to the team how various tasks/activities are done but also explains it to the external stakeholders.

21. Scrum Roles: Product Owner
Responsible for maximizing the value of the product.
Knows the business and the customer. So he/she defines user stories that matter to the business and the customer, and holds off on other stories.
Is the only person responsible for maintaining the product backlog.
He/she ensures that the user stories adhere to the DoR in terms of how requirements are described.

22. Artifacts 3x Customer Team Product Backlog Sprint Backlog Potentially
Shippable
Business
Value
Scrum
Master
Product
Owner

23. Scrum Artifacts: Product Backlog
A continuously evolving and ordered list of requirements and topics, required to ensure the optimal product value is achieved.
The product backlog is a single source of truth for modifications to the product.
All modifications are on a single list to ensure everyone has the same view on what modifications are desired.

24. Scrum Artifacts: Sprint Backlog
A set of product backlog items that have been selected for the Sprint.
Also contains tasks required for delivering the new feature at the end of a Sprint (for example, activities, such as develop, build, review, and test).
Contains an internal prediction of the Development team only for the next increment.

25. Scrum Artifacts: Potentially Shippable Product
The product increment, which is delivered at the end of each Sprint.
If the business requires, this artifact can be shipped to production straight away as it does not have any outstanding tasks.

26. States 2x Ready Done Customer Team Product Backlog Sprint Backlog
Potentially
Shippable
Business
Value
Scrum
Master
Product
Owner

27. Scrum States: Definition of Ready (DoR)
A list of rules describing standards that must be adhered by user story in order to be accepted by the Development team.
Ensures requirements are clear from its inception and additional conversations during the Sprint activity are kept to an absolute minimum.
Eliminates the need for discussions as much as possible.

28. Scrum States: Definition of Done (DoD):
A list of criteria describing which topics need to be addressed in order for a product to be considered “potentially shippable”.
Containing restraints, such as code, unit plus coverage tested, functionally tested, performance tested, user acceptance tested, reviewed, and documented.
The team only delivers that part of the product which adheres to criteria in the list.

29. Events 6x Ready Done Customer Team Product Backlog Sprint Review
Daily
Standup
Sprint
Planning
Tasks
Potentially
Shippable
Business
Value
Product
Backlog
refinement
Scrum
Master
Team
Retrospective
Product
Owner

30. Scrum Events: The Sprint
A predefined amount of time during which activities on the Sprint backlog are performed.
Sprints are often defined per week or every two weeks, but longer duration is also used.
Shortening a Sprint results in shorter backlog refinement, poker, and retrospective sessions as the number of topics to discuss will become much lesser as well.

31. Scrum Events: The Daily Stand up
Every day, the team comes up to the Scrum Board where each member will explain what he/she did yesterday, where he/she is now, and what he/she will be doing today.
Impediments, blocking team members from progressing, are also raised in this standup.
A standup should never take more than 15 minutes of time.

32. Scrum Events: The Planning Poker Session
At the start of each Sprint (and often during the backlog refinement session), the team plays Planning Poker in order to quantify the amount of work that is required to fulfill a new activity.
A sizing is agreed by the entire team and a ‘common view’ is established on the topics at hand.
Sizing will become more reliable over time, so the team starts to exhibit a specific burn rate, defining how fast the team is performing.

33. Scrum Events: The Sprint Review (Product Demo)
Each Sprint closes off with a product demo for the team, Product Owner, and the business/customer.
A way to provide and receive feedback from all stakeholders and inject this feedback into the product during the next Sprint.
Attending the product demo is essential for improving collaboration, the next product backlog, and the product!

34. Scrum Events: The Team Retrospective
After every Sprint, the team evaluates what went well and what went not-so-well, thus could improve.
This is an important aspect of Scrum to continuously improve on the way of working.

35. Scrum Events: The Backlog Refinement Session
Used to anticipate and define what user stories are expected in the next Sprint
Communicate uncertainties if user stories are unclear.
Typically takes place halfway to a Sprint.
leaving room for business and Product Owner to improve user stories where required before next sprint.

36. The Scrum Flow 1 5 4 2 3 5 6 7 8 Ready Done Customer Team
Sprint
Goal 1
Customer
Team
Sprint
Review
Product Backlog 5
Sprint
Backlog 4 2
Daily
Standup 3
Sprint 5
Tasks
Potentially
Shippable
Business
Value
Planning 6
Product
Backlog
refinement
Scrum
Master
Team
Retrospective 7 8
Product
Owner

37. Scrum Flow
Together with Product Owner, the team defines the goal for the next Sprint.
The team performs a Planning Poker session to determine the number of stories for the Sprint.
The tasks that fit the Sprint and adheres to the rules of DoR, such as tasks are clear enough to be fully processed by the team, are added to the Sprint backlog.
The Sprint starts and engineers will work uninterrupted on agreed tasks. The Product Owner is not allowed to update tasks/user stories in the middle of the Sprint.

38. Scrum Flow
At the end of the Sprint, the updates are demonstrated to the customer.
The Sprint review (a retrospective) is performed allowing the process to improve.
A product backlog refinement is conducted to help the Product Owner to get user stories to a state where they adhere to DoR. This activity can also be performed in the middle of a Sprint if required.
The Product Owner adds updated stories to the product backlog.

39. Social Objects 3x 1 5 4 2 3 5 6 7 8 Scrum Board BurnDown Chart
Impediment
Board
Social Objects 3x
Ready
Done 1
Customer
Team
Sprint
Review
Product Backlog 5
Sprint
Goal
Sprint
Backlog 4 2
Daily
Standup 3
Sprint 5
Tasks
Potentially
Shippable
Business
Value
Planning 6
Product
Backlog
refinement
Scrum
Master
Team
Retrospective 7 8
Product
Owner

40. Social Objects: Scrum Board
A board that lists the various activities for the current Sprint to be completed.
e.g: Kanban board, where activities move from left to right over the board from “To do”, “Doing”, “Done” or “Impeded”.

41. Social Objects: Scrum Board

42. Social Objects: Burn Down Chart
During a Planning Poker session features are assigned velocity points.
Points for all features of a Sprint delivery added to Burn Down chart.
Whenever a feature is implemented, the “burned” points are deducted from the total. The aim for each sprint is “0” burned points left.
First it’s difficult but over time estimations becomes more reliable.
Outlines burn rate for running the Sprint over times. Team can steer on making the required progress to burn all points for the Sprint.

43. Social Objects: Burn Down Chart

44. Social Objects: Impediment Board
This board contains all (external) topics which prevent the team from doing its work.
Typically, the Scrum Master ensures impediments are handled.
e.g: “not enough desks”, “team divided over multiple locations slows us down”, and “network is down several times a day”.

45. Improve Product Backlog
Scrum
Board
BurnDown
Chart
Impediment
Board
Ready
Done 1
Customer
Team
Sprint
Review
Product Backlog 5
Sprint
Goal
Sprint
Backlog 4 2
Daily
Standup 3
Sprint 5
Tasks
Potentially
Shippable
Business
Value
Planning 6
Product
Backlog
refinement
Scrum
Master
Team
Retrospective 7 8
Product
Owner

46. Improvement Cycle: Improve Product Backlog
The backlog, product, and collaboration are improved over time during each of the product demo sessions.

47. Improve Process 1 5 4 2 3 5 6 7 8 Scrum Board BurnDown Chart
Impediment
Board
Ready
Done 1
Customer
Team
Sprint
Review
Product Backlog 5
Sprint
Goal
Sprint
Backlog 4 2
Daily
Standup 3
Sprint 5
Tasks
Potentially
Shippable
Business
Value
Planning 6
Product
Backlog
refinement
Scrum
Master
Team
Retrospective 7 8
Product
Owner

48. Improvement Cycle: Improve Process
The process is improved over time during each retrospective in which topics for improvement are discussed.

49. Some Advantages of Agile
Visibility
Risk
Business Value
Security

50. Agile Development (Continuous Delivery) Traditional Development
Visibility
Product Owner and business are involved with product development on a regular basis
By attending the Sprintly demo or by launching new shippable features on a regular basis, visibility of what to be delivered is far higher.
Agile Development (Continuous Delivery)
Traditional Development

51. Agile Development (Continuous Delivery) Traditional Development
Risk
Optimization of product visibility lowers the risk.
It becomes clear early in the process whether the team is moving into the right direction and building the right product.
It is all about feedback and using this feedback to lower risk.
Agile Development (Continuous Delivery)
Traditional Development

52. Agile Development (Continuous Delivery) Traditional Development
Business Value
By delivering a shippable product at the end of each Sprint, the product can be used to generate business value throughout the product development cycle.
Features are prevented to get ‘stuck’ in the development cycle and are shipped straight away.
Force the team to consider the valuable feedback of the end-customer through the software development cycle
Agile Development (Continuous Delivery)
Traditional Development

53. Security
Delivering a product in a continuous manner have a positive effect on security-related topics as defects will be fixed faster.
Building just the functionality that is actually used by the customer, the “risk-surface-area”* will be kept to a minimum.
The team will work more coherent towards securing quality aspects of the product as they will be focused on the delivery of a product as opposed to performing activities which in itself have no meaning.
* Risk-surface-area: typically the code amounting to functionalities seldom or even never used

54. Minimal Viable Product (MVP)
MVP reflects your end-product in a minimal functional form.
It is used to test new ideas and verify whether the hypothesis are correct.
Idea
Learn M
Build
MVP
Measure
Data
Code

55. MVP in Agile
Selection of work from product backlog must be done in such a way that an MVP is delivered at the end of the sprint.
Users should receive a usable product that has value.
Feedback helps to ensure the right items are added to the product backlog.

56. Story Mapping
an engaging activity where all participants are involved in the process of building product backlog on a wall.
Steps
Advantages:
Lower risk in development
Engaged Customer
Shorter project startup time
Fast ROI
Details

57. The extra work is inside the features
How does it work?
A way to build your MVP in an iterative manner using Agile methodologies to engineer the solution.
Helps business, product owners, and engineers to prioritize the improvement of their product
End-to-end workflow
Overall
Goal A B C D
Fully
Functional } A1 C1 D1 M
MVP
Necessity,
Alternatives,
Flexibility,
Intelligence,
Performance,
Comfort,
Luxury…
Marketable
Feature Set B1 A2 B2 B3 A3 C2 D1
The extra work is inside the features D2
Fully
Featured

58. The extra work is inside the features
Slices
Defining slices ensures each iteration contains a set of features that has value for the customer.
Later slices include enhancements to previously created functionality.
End-to-end workflow
Overall
Goal A B C D
Fully
Functional }
Walking skeleton A1 C1 D1 M
MVP
Marketable
Feature Set B1 A2
Slice 1 B2 B3
Slice 2 A3 C2 D1
The extra work is inside the features D2
Slice 3