Agile MethodologyGenerally tasked with the logistics of making a project work, like budgeting and risk management.
What is Agile?
Agile is an approach to project management that centers around incremental and iterative steps to completing projects. The incremental parts of a project are carried out in short-term development cycles. The approach prioritizes quick delivery, adapting to change, and collaboration rather than top-down management and following a set plan.
What is Scrum?
Scrum is one of the most popular agile frameworks for product development.
Scrum teams are a bit different from regular teams because their work is organized around a series of sprints – 2-4 week periods of work – during which they work on small and discrete increments of work to get quick feedback from stakeholders. Within each sprint are a number of Scrum ceremonies or Scrum meetings that add structure to a team’s work.
Scrum Team -
Scrum teams are a bit different from regular teams because their work is organized around a series of sprints – 2-4 week periods of work – during which they work on small and discrete increments of work to get quick feedback from stakeholders.
Scrum team includes 3 to 9 members made up of Scrum Master, a Product Owner and numerous developers or designers.
Scrum Ceremonies -
Sprint Planning -
Sprint Planning initiates the sprint by laying out the work to be performed for the sprint. This resulting plan is created by the collaborative work of the entire Scrum team.
Participants: Developers, Scrum Master, Product Owner.
Timing: The Sprint Planning meeting occurs at the start of the sprint. It can last anywhere from one to two hours for a two-week sprint.
During Sprint Planning, the Scrum team commits to the tasks they will complete in the upcoming sprint. They do so by moving items one at a time from the Product Backlog—a collection of all tasks that could be done—to the Sprint Backlog or simply the Todo list for that sprint.
The Product Backlog is a prioritized list of all the things a team could do. These tasks are often referred to as User Stories or simply ‘Stories’. Sprint planning keeps the team focused on what the team should do during the next sprint, by pulling the highest priority stories into the Sprint Backlog.
The product owner’s task is to prioritize the Backlog column before this ceremony starts, with the most critical and urgent tasks appearing at the top.
NOTE: Virtual Kanban tool like Trello, Jira, GitHub, or Confluence.
Daily Scrum (Daily Standup) -
The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. Doesn’t run over 15 minutes.
Participants: Developers, Scrum Master, Product Owner.
Timing: Same time and place every working day of the Sprint, no longer than 15 minutes.
The Daily Scrum is a short, daily ceremony that helps team members share progress, unblock each other, and sync-up on work. Because it brings the whole team together every day, you can share and remove obstacles quickly so everyone can continue in flow toward the Sprint Goal.
During the Daily Scrum, every developer typically answers some version of these three standup questions:
What did you do yesterday?
What will you do today?
Is anything blocking your progress?
Sprint Review (Sprint Demo) -
The purpose of the Sprint Review is to inspect the outcome of the sprint and determine future adaptations. The Scrum team presents the results of their work to key stakeholders, and progress toward the Product Goal is discussed. The heart of this ceremony is a demonstration of actual product functionality based on the tasks from the sprint.
Participants: Developers, Scrum Master, Product Owner, Project Stakeholders.
Timing: The Sprint Review meeting occurs at the end of your sprint. It usually lasts 30–60 minutes. According to the Scrum Guide, the recommended maximum is four hours for a one-month sprint.
This meeting occurs at the end of your sprint. It usually lasts 30–60 minutes.
You’ll determine if you met the Sprint Goal you set in the Sprint Planning meeting and discuss how to improve the product further in future sprints. Sprint Reviews let stakeholders can give feedback early and often, instead of rarely and late. When the latter happens, it’s harder to pivot, or only at great cost.
Sprint Retrospective -
The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.
Participants: Developers, Scrum Master, Product Owner (optional)
Timing: As a general rule, take 30–45 minutes for each week of your sprint. The retrospective of a two-week sprint should last roughly one hour.
The Sprint Retrospective helps teams build a habit of continuous process improvement. During this ceremony, the Scrum team figures out what they can improve by inspecting how the last sprint went. Individuals, interactions, processes, tools – anything is up for review and discussion.
Also, take time to celebrate what went well – give kudos to a colleague, and discuss how to replicate successes in the future. Like the Sprint Review, it takes place at the end of the Sprint, but its focus is on processes, not the product.
NOTE: Sprint Reviews focus is on the product whereas Sprint REstrspectives focus is on the process.
Backlog Refinement -
Product Backlog Refinement is the act of breaking down and further defining Product Backlog items into smaller, more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.
Participants: Product Owner, Developers
Timing: It’s complicated…
During Backlog Refinement, you add more and more details to your Backlog items so that they’re in great shape when you pick candidates for the next sprint during Sprint Planning. Those details may include a clear User Story, Acceptance Criteria and estimated effort.
Requirements: Business, User and Solution (Functional and Non-Functional)
Business Requirements (Business Goals / Objectives) -
Business Requirements defines what and why part of the business goals. It never offers or proposes solution. These include high-level statements of goals, objectives, and needs. Business requirements do not include any details or specific features. They just state the problem and the business objective to be achieved such as
increased revenue/throughput/customer reach,
reduced expenses/errors,
improved customer service, etc.
The business goals or objectives should be specific, measurable, achievable, relevant, and time-bound (SMART) to ensure they are feasible and aligned with the business goals.
User (stakeholder) Requirements -
Specifies what users (stakeholders) expect from a particular solution. This group serves as a bridge between the generalized business requirements and specific solution requirements. They are outlined in a User Requirements Specification and can include, for example, ability to create various reports, view order history and status, manage customer databases, etc.
Solution Requirements: Functional and Non-Functional
Solution requirements describe specific characteristics that a product must have to meet the needs of the stakeholders and the business itself.
They fall into two large groups -
(1) Functional Requirements -
Defines the how part - 'How' system needs to operate to achieve a business goals. Proposes solution, system specifications, technical in nature.
They are product features or functions that developers must implement to enable users to accomplish their tasks. So, it’s important to make them clear both for the development team and the stakeholders. Generally, functional requirements describe system behavior under specific conditions. They are composed of: if/then behaviors, description of the system’s workflow, logic behind data handling, and data inputs and corresponding outputs. For example:
(1) The system sends an approval request after the user enters personal information.
(2) A search feature allows a user to hunt among various invoices if they want to credit an issued invoice.
(3) The system sends a confirmation email when a new user account is created.
(2) Non-Functional Requirements -
Describe the general properties of a system. They are also known as quality attributes.
They are not related to the system functionality, rather define how the system should perform. The common types are: performance and calability;
portability and compatibility; reliability, availability, maintainability; security; localization; and usability. Some examples are:
(1) The website pages should load in 3 seconds with the total number of simultaneous users <5 thousand.
(2) The system should be able to handle 20 million users without performance deterioration.
(3) Here’s a brief comparison and then we’ll proceed to a more in-depth explanation of each group.
Requirements are usually written in text, especially for Agile-driven projects. However, they may also be visuals. Here are the most common formats and documents:
(1) Software Requirements Specification (SRS) document
(2) Use cases
(3) User stories
(4) Work Breakdown Structure (WBS), or functional decomposition
(5) Prototypes
(6) Models and diagrams
Software Requirements Specification (SRS) Document -
The SRS is written in a single document communicating functional and non-functional requirements. Its a technical document that describes future software functions and capabilities, its characteristics, design, and implementation constraints for the development team.
SRS is at the bottom of the software requirements hierarchy, which goes like this:
Top tier – the high-level business requirements (BRs) dictating the goal behind the product,
Middle tier – user requirements (URs) that picture the end-users and their needs, and
Bottom tier – SRSs that specify the product’s functionality in tech terms.
Source: altexsoft.com
It usually comes in a form of user stories or use cases.
User stories are more suitable when describing the system itself, while use cases describe how a user interacts with this system.
Source: altexsoft.com
Visualize: Enriching your SRS with visuals like diagrams, schemes, and models contributes to a better understanding of the processes. For visuals, a nice technique is mind mapping as it organizes ideas (critical features and scenarios) generated during brainstorming and shows connections between them.
Source: altexsoft.com
Content Sources and Additional Reference:
Functional and Nonfunctional Requirements: Specification and Types
How to Write Software Requirements Specifications: Best Practices and SRS Tools
Use Cases
Use cases describe the interaction between the system and external users that leads to achieving particular goals.
Each use case includes three main elements:
Actors. These are the external users that interact with the system.
System. The system is described by functional requirements that define an intended behavior of the product.
Goals. The purposes of the interaction between the users and the system are outlined as goals.
There are two formats to represent use cases:
Use case specification structured in textual format
Use case diagram
Content Sources and Additional Reference:
Functional and Nonfunctional Requirements: Specification and Types
User Story
A user story describes the system itself. It describes software feature seen from the end-user perspective and what exactly the user wants the system to do. In Agile projects, user stories are organized in a backlog, which is an ordered list of product functions. Currently, user stories are considered to be the best format for backlog items.
User stories describe the value a user wants from a product without dictating how to create this value. This approach allows the Agile team to find the best solution to meet the user’s needs.
User story formats -
A user story typically includes three components:
User role (Who):
The person or role who will use the feature. This element helps the team understand the context and perspective of the user. For example, you could simply write “as a user” or define further with a specific role: “as a systems administrator.”
Action or goal (What):
The action the user wants or needs to take or the outcome they hope to realize.
Benefit or value (Why):
The value or benefit the user hopes to get from their action. It’s why the user wants to perform the action or achieve the goal.
"As a [User Role], I want [Action or Goal] so that [Benefit or Value].”
Example:
As an admin, I want to add descriptions to products so that users can later view these descriptions and compare the products.
User stories must be accompanied by acceptance criteria. These are the conditions that the product must satisfy to be accepted by a user, stakeholders, or a product owner. Each user story must have at least one acceptance criterion. Effective acceptance criteria must be testable, concise, and completely understood by all team members and stakeholders.
All user stories must fit the INVEST quality model:
I – Independent
This means that you can schedule and implement each user story separately. This is very helpful if you implement continuous integration processes.
N – Negotiable
This means that all parties agree to prioritize negotiations over specification. This also means that details will be created constantly during development.
V – Valuable
A story must be valuable to the customer. You should ask yourself from the customer’s perspective “why” you need to implement a given feature.
E – Estimable
A quality user story can be estimated. This will help a team schedule and prioritize the implementation. The bigger the story is, the harder it is to estimate it.
S – Small
Good user stories tend to be small enough to plan for short production releases. Small stories allow for more specific estimates.
T – Testable
If a story can be tested, it’s clear enough and good enough. Tested stories mean that requirements are done and ready for use.
Content Sources and Additional Reference:
Functional and Nonfunctional Requirements: Specification and Types
Planning Poker
Planning poker is a game-like estimation technique that teams can use to predict the effort they’ll need to exert for each task on the project. It should usually happen in a sprint planning session before the start of a sprint.
The project manager (or Scrum master, if it’s an agile team) is usually the one to facilitate a session, but it does not always have to be. Any member of the project team can facilitate or act as a moderator for a planning poker estimation session.
Much like the game of poker in real-life, participants in a planning poker estimation session are given a deck of cards. The cards are numbered to represent different values to measure the time, effort and level of complexity required to complete a task. The cards represent numbers that represent the Fibonacci sequence (reflects an abstract sizing scale/sequence 0, 1, 2, 3, 5, 8, 13, 21).
Team members select a card that best represents their estimate of the task’s effort, duration, and complexity. The number of the card (and its associated value) is equal to the number of story points that the task (or user story) is estimated to be.
Additional Reference:
What Is Planning Poker & How It Works: 5 Easy Steps
Kanban Board
Kanban boards is tool for visualizing progress throughout the life cycle of a project.
Kanban is a Japanese word for “sign board,” which in this application is intended to help visualize work processes or tasks.
It is typically composed of lists, or “columns,” which show a progression from start to finish.
The columns often include categories such as To Do, Doing, and Done. Cards are used to represent tasks and can be moved from one column to another as they progress through the queue. By following the cards and their movements across the board, teams can quickly see where tasks stand in the project management pipeline.
Kanban Board v/s Scrum Board -
Kanban and Scrum as methodologies are different in structure, purpose, roles, and tools. With that said, a Kanban board can be a very helpful tool within an individual Scrum iteration or sprint.
Kanban boards are tools to visualize work as it moves throughout a defined process, so within a Scrum iteration, that means that a Kanban board can be used to monitor the progress of individual tasks from the beginning of the process to the end.
Additional Reference:
What Is A Kanban Board & 4 Best Use Cases