Agile Methodologies

Scrum Artifacts

By: Ed Vogel

Nov 2018

Introduction

This article provides an overview to the three most basic artifacts for scrum. These include the product backlog, sprint backlog and burndown chart.

The Product Backlog

The product backlog contains the future work that is a set of un-developed stories / features yet to be developed. The product owner is responsible for prioritizing the product backlog in order of importance for the largest current return on value or need. A good general rule for the prioritization of the product backlog is having stories prioritized and reviewed by the team for the next 4 - 6 weeks worth of work. This is accomplished through weekly product backlog grooming. This backlog grooming should occur at a minimum of once every two weeks, though I personally prefer to do this in shorter sessions every week. As a rule of thumb, try to shcedule about 1 hour of grooming for each week making up a sprint.

The backlog grooming sessions include the Product Owner, Scrum Master and the Team. Do not underestimate the importance of having the product owner present for these meetings. This is the time that the team is able to determine what will required to complete a story to the DoD (Definition of Done). As they proceed through each of the stories, conversations are had to bring everyone on the same page for development of each story. The goal of this process is to come away with stories having well discussed having : Intuative Names, Descriptions, Acceptance Criteria. Stories should strive to be INVEST. INVEST is an acronym for: Independant, Negotiable, Valuable, Estimable, Small, Valuable. Rather than delve into this aspect here try reading, AgileForAll - INVEST. Quite often stories will be broken down into more manageable pieces which are just smaller stories. Features are broken into stories, and stories can be split into more stories. In short, we strive to make the stories into manageable pieces which can be completed somewhere between 8 and 40 hours.

The Sprint Backlog

The sprint backlog is a set of stories planned for a sprint. This is where the importance of prioritizing the stories really shows itself. The team will select stories in order of importance from the product backlog into the sprint backlog while adding up the story points until the teams velocity is met. Story points and velocity are not explained in depth in this article.

Assuming the product owner has ranked a the stories accordingly, by value and also dependencies. The team starts from the top of the product backlog and down the list. The team will discuss each of the stories and confirms the story points for each. The greatest appeal for the ranking according to value is the project is always implementing the stories which give the most value, bang for the buck.

The Burndown Chart

The Burndown chart is a great visual indicator to the team's progress through the sprint. In its simplist form there are four components:

X axis shows the working days in the sprint
Y axis shows the work to be completed
Ideal progress trend line
Actual progress trend line

At the end of each day the team updates their work completed so it is reflected on the burndown chart. The cumulative remaining work for each day will show the trend for completing work throughout the sprint. The chart provides transparency about current performance and a means to determine if corrective actions should be teaken to meet the sprint commitments. Note: Let me state that the burndown chart is NOT a reporting tool for management. It is not a daily progress report.

Full article >>;

Agile Foundations

By: Ed Vogel

Oct 2018

Introduction

The Agile Manifesto was created in 2001 by a group of software developers attempting to find a better way to develop software from the standard paradigms at the time. This was a repsonse to the large numbers of failed projects due to monolithic project management practices.

Agile Manifesto

Individuals and processes over tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Above all, Agile relies on communication. Communication among the team, communication with stakeholders and constant feedback to drive work in the correct direction to fullfill customer satisfaction.

Principles behind the Agile Manifesto

We follow these principles: 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.

Source: Agile Manifesto

Agile provides constant feedback from the customers / users. That is a tremendous leap forward in software development. For years requirements were elicited from the client prior to development(planning phase) and developers would not interact with the client until project completion. On projects that last many months, if not years that leaves a huge gap where things can really go off track. We can all agree that changes found earlier are cheaper to correct than ones found later in the project. By involving the clients from the beginning and having regular checkins during the development process we allow for changes to be managed if a far more effective way. Validation Á verification - did we build what was asked of us and more importantly did we build what the client wanted. These two paths can severely diverge with out regular client feedback. Agile, especially Scrum, provides regular client feedback so our projects can change direction as soon as changed are identified. Hence, Agile.

Full article >>

Meeting guidlines for the Daily Standup

By: Ed Vogel

Oct 2018

Introduction

The daily Standup also know as the Daily Scrum is the held every day at the same time. This is the time all team members report on on where they are for a 48 hour time period, the 24 hours prior to the meeting, the next 24 hours along with any impediments. The following is a set of guidelines on how to get the most from the stand up from the Scrum Master and Team Members. You may notice the Product Owner is not listed, the PO may attend the meetings but should not be involved during the Stand Up.

Team Members

Arrive on time or early.
Be ready to say what you did yesterday and what you plan to do today.
Report any impediments impeeding your progress.
Keep your report specific, precise and short in order to help the meeting end within 15 minutes.
Listen to other team member's status in case it might relate to your tasks or impact you.
Don't interrupt people when they are talking.
If you raise an issue or question that can't be resolved in a minute, ask to discuss with the parties involved after the meeting.
For team members calling in, be sure to start by identifying yourself by name before reporting.

Scrum Master

Be sure to have (or have access to) your relevant information (the sprint or product backlogs, the software being developed, or the project, requirements or design documents and code)
Be sure to have scheduled the recurring meeting and invited all appropriate people
Be sure that the invitation includes the relevant information, such as project, meeting location, project site URL, and conference number.
It is your job to keep the meeting focused and starting and ending on-time.
It is your job to know why and how scrum works. Look for teachable moments in the daily scrum.

The Daily Stand Up is a great ritual to keep all of the team in synch with each other. It allows for everyone to understand where all of the team menbers are at that point during the sprint. You would be surprised how many issues can be solved by simply having all the members hearing about it and possibly providing guidence from previous experience or personal knowledge.

Full article >>

Scrum Rituals

By: Ed Vogel

Sep 2018

Introduction

The following article describes the Scrum Rituals at a high level. We will provide the reader with the general flow of scrum.

Below you can see a very common image showing the Scrum rituals and their interacttion and flow.

Product Backlog

This holds the features and functionality the product will contain. It is the Product Owner's responsibility to prioritze the items in the backlog as User Stories. By prioritizing the User Stories according to business value the current highest value features are always next in line to be developed.

Sprint Backlog

The subset of requirements that the Team commits to accomplishing for a given Sprint.

Sprint

A short, fixed period of time (usually 1-4 weeks) where the team is focused on completing a specific Sprint Backlog.

Daily Scrum (Stand Up)

The Team has a short (15 minutes or less) daily meeting during which team members report on what they accomplished since the last meeting, what they plan to accomplish that day, and report any impediments or blockers to making progress.

Sprint Retrospective

The Team regularly reflects on what and how to improve their productivity and quality.

Sprint Review

The Team reviews the work that was completed for the iteration with the Product Owner and business stakeholders.

Full article >>

The Project Management Citadel