I recently had the chance to join Henrik Lindberg from Acando for an Agile Scrum workshop. In this post I will write about the workshop and the basics of Agile and Scrum. There is so much to learn and explore in agile, and I hope this introduction will compel further reading.
Unless you live offline, you probably are aware of the latest trend in the corporate world, which is the agile approach. Agile, in recent times has grown into a revolutionary movement that is transforming the way professionals work. Agile is a methodology that keeps the equilibrium of your priorities. Thus, the work is done faster, and project requirements are with great efficiency.
Working agile, people tend to forget about the four values from the agile manifesto:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Equally important is the twelve principles behind the 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.
- Business 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.
- 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.
- 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.
Major Differences between Waterfall and Agile
- The waterfall approach is a sequential model of project management. Here the development team can only move to the next stage if the previous step is successfully completed.
- In the agile approach, the execution of processes is concurrent. This enables effective communication between the client, the manager, and the team.
- Waterfall assumptions are not well-suited for large-sized projects, whereas agile lets you manage complicated tasks with great ease.
- Agile methodology is being embraced by managers worldwide for its greater flexibility.
- The development plan is reviewed after each step in case of agile, while for the Waterfall approach it will be only during the test phase.
The agile development is based on the interactive functionality, according to which the planning, the development, the prototyping and many other key phrases of the development may pop up more than once in line with the project requirements. The agile also adheres to the incremental model, where the product is designed, implemented and tested in increasing order (complexity of the task increases in the ascending order). The development is termed as finished, only if every minute specification and requirement is met.
When to Use The Agile Methodology?
- In a Scenario, When You Require Changes to Be Implemented
- When the Goal of the Project Isn’t Crystal Clear
- When You Need to Add a Few New Features to the Software Development
- When the Cost of the Rework Is Low
- When Time to Market Is of Greater Paramount Importance than the Full Feature Launch
- When You Want to See the Progress in the Sequential Manner
Scrum is the latest agile framework for product success in small-to-big organizations, which is creating a lot of buzz in the present IT world. Managers’ worldwide united hold a belief that Scrum is far more than the execution of processes and methods; it plays an integral role by supporting teams meet their aggressive deadlines and complicated project demands. The Scrum is a collaborative agile approach that involves the breaking down of substantial processes into smaller tasks so that they are done efficiently in a streamline manner.
Scrum is a lightweight, agile framework that successfully manages and accelerates project development. This framework is proven to cut down on project complexity and focus largely on the building products that are in accordance with client expectations. Generally, people sometimes use Agile and Scrum as interchangeable, but there is a big difference. The agile approach is a series of steps, on the other hand, Scrum a subset of agile.
There are three principles of Scrum:
Are you interested in switching to the Scrum approach of development? Then, you must know the various Scrum roles.
The Product Owner
He/she is responsible for providing the vision of the product. The product owner will play the central role in breaking down the project into smaller tasks and then prioritize them.
- Defining the Vision
- Managing the Product Backlog
- Prioritizing Needs
- Overseeing Development Stages
- Anticipating Client Needs
- Acting as Primary Liaison
- Evaluating Product Progress at Each Iteration
He/she is someone with extensive expertise over the framework. The ScrumMaster will make ascertain that the development team is adhering to the Scrum model. They will also coach the team on this.
- Coaching the Team
- Managing and Driving the Agile Process
- Protect the Team from External Interference
- Managing the Team
- Foster Proper Communication
- Dealing with Impediments
- Be a Leader
The Development Team
This involves a panel of qualified developers those who form the core of the project development. Each individual in the team brings his/her own unique skills to the table.
- The Entire Team Is Accountable for the Work
- They Are No Titles and Subheading
- Sit Together to Communicate with One Another
Artifact #1: Product Backlog
Product backlog involves a sequence of fundamental requirements in a prioritized order. The requirements are provided by the provided owner to the Scrum Team. The backlog of product emerges and evolves with time, and the owner of the product is solely responsible for content & its validity.
Artifact #2: Sprint Backlog
It is the subset of the product backlog that the team will put in the hard efforts to achieve the “To Do’s.” The work in the sprint backlog is sliced down in smaller tasks by the team. All the items of the sprint backlog must be developed, tested, documented and integrated to meet the needs of the clients.
Artifact #3: Product Increment
The product increment is an artifact of Scrum with significant importance. The product increment must in line with the “Definition of Done” by the development team, and the product increment has to be approved by the product owner.
Definition of Done in Scrum Methodology
Definition of Done from varying from one scrum team to another. It is an acceptance criterion that drives the quality of work when the user story is complete. In other words, Definition of Done is the quality checklist with the development team.
The Burndown chart is a means to track the progress of a project on the Scrum. The ScrumMaster is responsible for updating this chart at the end of each sprint. The horizontal axis on the release Burndown chart represent the sprints, while the vertical one will make you aware of the remaining work at the beginning of each sprint.
Backlog refinement is the act of updating/adding estimates, details, and order for the items in the product backlog. This improves story descriptions.
Commonly known as the “Definition of Requirement,” the user story in Scrum provides enough information to the development team so that they provide a reasonable estimate for the project. The user stories are about one or two sentences, a set of conversations that define the desired functionality.
User Story Acceptance Criteria
Acceptance criteria in terms of Scrum methodology are a set of conditions that the software product must meet in order to the acceptance by the user, customer or the other stakeholders. In layman’s terms, it is also a set of statements that determine user features, requirements or functionalities of an application.
User Story Relative Estimation
Relative estimation is the procedure of estimating task completion. The estimate is not in terms of the time, rather the items that are similar to one another in terms of complexity.
There are five defined Scrum Events.
The Sprint Planning is an event in the Scrum framework. Here the team in a collaboration will decide on the task they will focus during that sprint, and discusses their initial plan to meet those product backlog tasks.
The sprint goal is defined as the objective set for the sprint that needs to be met via the implementation of the Product Backlog. The sprint goals are obtained after long discussions between the Product Owner and the Development team.
For the Scrum approach, each day of a Sprint, the team meets and holds a discussion on a number of aspects, and this meeting is known as the Daily Scrum.
The sprint review is held at the end of each of the sprint. This is done to inspect the product increment.
The Sprint Retrospective is held between the development team and the ScrumMaster to discuss how the previously Sprint went, and what can be done to make the upcoming Sprint more productive.
In the end, after reading this entire article, you probably got a basic overview of the Scrum approach. If you want to talk about agile and scrum, feel free to contact me at firstname.lastname@example.org. You can also read more about agile in this article: