Scrum, an Agile development methodology, is a framework for project management that emphasizes teamwork, accountability and iterative progress toward a well-defined goal. The three pillars of Scrum are transparency, inspection and adaptation.
We recommend using Scrum if:
The project requirements will change and evolve
Continuous feedback is required
You don’t need to commit to a fixed release date
The project team wants autonomy
Scrum works well for projects that have a lot of unknowns or that evolve over time. Scrum deals with these changes very effectively, so you can easily accommodate new information or features throughout the process.
A Scrum team needs three specific roles and one optional:
A Product Owner
A Scrum Master
A Development Team
A Customer (optional)
These three roles are coequal and all of them have certain responsibilities.
Roles & Responsibilities
Represents the Customer and the Business
Ensures the team has everything they need to deliver value. He/She acts as a servant-leader for the Development Team
Focuses on the working software delivery
The Development Team is cross-functional, self-managed, self-organized and dedicated. That autonomy is what makes scrum unique. It is the very core of the process. What comes from this approach is strong team bonds and a positive working environment where people feel empowered on the job.
Optional as the Customer can be the Product Owner
When the project is developed internally, the Customer is often the Product Owner.
When the project is developed externally, the Customer is responsible for:
Within Agile, the Project is paced by the Iterations. For each of them, the Scrum Master and Product Owner will put together a proposal for its content (aka Iteration Backlog) by defining a list of Backlog Items that takes into account criteria like Business Value, Epics or the past Velocity (i.e. the capacity to deliver Story Points). This is called an Iteration Planning Meeting.
The proposal is then discussed with the Team Members. Story Points estimates are reviewed so that eventually, the team can commit on the delivery of the Iteration Backlog. There are different ways to conduct this meeting like the Planning Poker technique.
During an Iteration, the team will meet every day for a short amount of time (Daily (Scrum) meetings) to discuss progress but more importantly any problems or technical difficulties.
At the end of the Iteration, all completed elements should be ready to be shipped (as part of their Release). A post-mortem meeting might be organized to discuss the difficulties encountered during the Iteration, review the Velocity and improve for the next Iteration.
The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. The Product Backlog replaces the functional specifications requirements found in the Waterfall methodology.
The Product Backlog has the following characteristics:
Each entry must have added value to the Customer.
Changes can occur throughout the whole project.
Low level tasks should not be described.
All entries are prioritized to order the Product Backlog.
All entries are estimated generally in Story Points.
The Product Backlog has to be maintained on an ongoing process by the Product Owner.
The Product Backlog is composed of Backlog Items.
A Backlog Item is a unit of work small enough to be completed by a team in one iteration. Backlog items are decomposed into one or more tasks.
When entered into the Product Backlog, Backlog Items can be user-centric. In that case, they will be written in the form of user stories.
A User Story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it. A User Story describes a piece of functionality from a user’s point of view, expressed in a solid, compact way. They reflect what a particular class of user needs and the value to be gained. The format is very simple and easy to use.
“As a <particular class of user> I want to <be able to perform/do something> so that <I get some form of value or benefit>"
However, writing User stories is not mandatory. Backlog Items can also be entered with few keywords or short sentences, as long as they are understandable by the Project Team and the Stakeholders.
The Iteration Planning meeting is attended by the Product Owner, Scrum Master, and the entire Project team. Outside stakeholders may attend by invitation of the team, although this is rare in most companies.
During the Iteration Planning meeting, the Product Owner describes the highest priority features to the team in order to define the Iteration goal. Then they determine the Backlog items they will work on during that Iteration after having ordered and estimated them.
An Iteration is one time boxed of a continuous development cycle. Within an Iteration, planned amount of work has to be completed by the team and made ready for review. The term is mainly used in the Scrum methodology. The generic term in the Agile approach is Iteration (the one used in Sciforma).
The average Iteration length is generally between 2 to 4 weeks.
When using the Scrum methodology, work estimations are not done in hours but in Story Points.
Story points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a Backlog Item or any other piece of work. When estimating with story points, a point value is assigned to each Backlog Item.
Scales like the following ones are often used to help estimating Story Points:
The Fibonacci sequence numbers (0.5,1, 2, 3, 5, 8, 13, 21,...)
The linear sequence numbers (1, 2, 3, 4, 5, 6, 7, 8, …) – Used by Sciforma
As the exercise might be done collaboratively, some companies use techniques like Planning Poker.
The Product Owner presents the Backlog items that need to be estimated. The Team Members ask questions and the Product Owner gives more details.
Each Team Member who gets a set of cards privately chooses the card representing the estimate.
When all Team Members have made their estimates, they reveal their cards at the same time. If all estimates are the same, a new Backlog item is selected and the same process is repeated. When estimates differ, the Team Members discuss the issue to find a consensus.
When Backlog items have been estimated, Story Points will have to be compared to the Team Velocity.
The Team Velocity is based on actual Story points completed, which is typically an average of all previous Iterations. The Team Velocity is used to plan how many Backlog items the team can plan and complete during the next Iteration.
However, to know the Backlog items that could be taken into account in the next Iteration, the Project Team Capacity will also have to be considered. The Capacity is how much availability the team has for the Iteration. Thus, it could vary if Team Members are on vacation, sick, etc.
The Iteration Backlog is a subset of the Product backlog. The Iteration backlog comes from the Product Backlog, and contains those Backlog items that can be completed during the Iteration.
Unlike the Product Backlog, Iteration Backlog is unchanged during the period of the Iteration. Indeed, at the end of the Iteration planning, the Backlog items and steps to complete them are frozen for the length of the Iteration. If there are Backlog items left unfinished by the end of the Iteration, they will be added back to the Product Backlog and addressed during the next Iteration.
At a high level, a project may start as epics, themes, or features, which are then broken down into Backlog items.
Tasks are used to break down Backlog items even further, when necessary. Tasks are the smallest unit used to track work. A task should be completed by one person on the team. Typically, each Backlog item will have multiple associated tasks. Because the team is cross-functional, having tasks for a single Backlog item allows team members to work in parallel on their area of functional expertise to complete the item as a team.
Thus, breaking Backlog items down into tasks helps the team determine how they will approach the work to be done. By getting into this level of detail, any unknowns will be uncovered.
The goal of Daily Scrum Meetings (a.k.a. Daily Stand-up Meetings) is to quickly inform everyone of what’s going on across the team. The meeting which is strictly time-boxed to 15 minutes, is held by the Scrum Master who will ask 3 questions to each Team Member.
What did you do yesterday?
The Scrum Master wants to know what tasks are "done" and whether tasks in progress will complete as expected. If estimates are expanding or new tasks are discovered, this will change the burndown chart.
What will you do today?
This question replaces GANTT charts. Dependencies are constantly changing. Answering this question revises project strategy on a daily basis by reorienting the team due to dependency changes that were revealed by the previous question.
Are there any blockers or impediments preventing you from doing your work?
The most important effect of this question is to create a list of impediments that are assigned to the team or escalated. A major responsibility of the Scrum Master is to manage, prioritize, and assure this impediment backlog is burned down.
The Task Board is a visual display of the progress of the Project team during an Iteration. It presents a snapshot of the current Iteration backlog allowing everyone to see which tasks and Backlog items remain to be started, which are in progress and which are done.
The Task Board is updated every day during the Daily Scrum Meeting.
A Burndown chart is a graphical representation of work left to do versus time.
The X axis of the chart always indicates time (usually in days).
The Y axis represents the remaining work to be done in the Iteration. This may be represented by either Tasks Remaining (in # of tasks) or Remaining Effort (in Story Points/Hours).
The Progress line indicates how your team is progressing with their Iteration. It gets updated every day with the new remaining estimates. As the Iteration progresses, this line will indicate whether your team is on track and if any corrective action is needed.
The Guideline is a diagonal line drawn downwards, from left to right on the graph. Your Iteration progress line should ideally be as close to the guideline as possible. If your team is able to complete all stories at a steady pace throughout the Iteration, your progress line will end up looking exactly like the guideline.
If the Iteration Progress line is above the guideline, it means that the Project Team is behind schedule and should have completed more work at this point.
If the Iteration Progress line and the guideline are closed together, it means that the Project Team will complete all the work if it maintains its velocity.
If the Iteration Progress line is below the guideline, it means that the Project Team is ahead of schedule and should complete all the work before the Iteration’s end date. In that case, the Project Team can add new Backlog items in the Iteration to ensure they will be occupied until the Iteration’s end date.
At the end of the Iteration, the Product Owner invites the Project Team and key stakeholders to the Iteration Review Meeting. During this meeting, the outcome is inspected throughout a demo so that everyone can provide feedback on the work done.
The purpose of the Iteration Review isn’t to provide a status update or a presentation to stakeholders. It is to collect and process feedback on the actual Increment.
Here is the typical agenda of an Iteration Review Meeting:
The Product Owner explains what Backlog items have been “Done” and what has not been “Done”.
The Project Team discusses what went well during the Iteration, what problems it ran into, and how those problems were solved.
The Project Team demonstrates the work that it has “Done” and answers questions about the Increment.
The Product Owner discusses the Product Backlog as it stands, and likely, projects target and delivery dates based on progress to date if need be.
The entire group collaborates on what to do next, so that the Iteration Review provides valuable input to subsequent Iteration Backlogs.
The Iteration Retrospective Analysis occurs after the Iteration Review and prior to the next Iteration Planning. As this meeting is a time to discuss on the just delivered Iteration, the Project Team, the Scrum Master, and the Product Owner attend it.
The goal of the retrospective is for the team members to discuss among themselves how the work went during the last Iteration so that better ways can be found to meet the project’s goals and improve productivity. All members discuss failure and future improvements, and keep track of the lessons learned.
The Iteration Retrospective Analysis could be compared to the Post Mortem meeting found in the Waterfall Methodology. However as it occurs at the end of each Iteration and not at the project’s end, process adjustments can be done more frequently and small improvements can be implemented regularly.
An Agile Organization is one that is quick in responding to changes in the marketplace or environment. A highly agile organization reacts successfully to the emergence of new competitors, rapid advancements in technology and sudden shifts in overall market conditions.
What is not an Agile Team?
An Agile team is not simply a project team made up of various different people from different areas of the business, such as a Task Force.
An Agile team is not solely developer resources. It is not a Matrix team either.
What is an Agile Team?
An Agile team is a cross-functional group of people that is self-contained to the point that the people in the group can deliver the product (or the next iteration of it) without needing to draw on skills outside the group.
An Agile team is a dedicated group of people who do not move between products or teams just because another work gets a higher priority.
An Agile team is self-organized. It has therefore the responsibility and the authority to create a functional, internal team structure by replacing, retraining or reorganizing team members as needed.
An Agile team is self-managed. Team members are responsible for planning, executing, monitoring and managing their activities under reduced or no supervision.
One has to remember that Agile is an approach and a mindset that are adaptative. It is up to each company to adapt the organization to make it work for their projects.
Sciforma Data Model has been implemented to fit the customers needs and requirements.
Stories, Defects, Tasks and Issues are all managed as Backlog Items.
This will ease the project progress particularly when using the Task Board as all the Backlog Items are managed at the same level.
Besides, Backlog Items may have an Items Checklist attached to them. Those items can be converted to Tasks. In that case, a connexion will be created between the Backlog Item and that newly created task.