At ThreeWill, we have adopted Scrum as our Agile Framework. We have found that the Scrum processes have been the best and most lightweight processes that reinforce what we have always found successful on projects. The “Inspect and Adapt” principles of Scrum are great for having tight feedback loops on projects and are ideal for effective expectation management.
What Is Scrum?
A great overview of our process can be best described by the below process diagram that was created by Mike Cohn of Mountain Goat Software (Mike is an excellent teacher of Agile Principles). This helps you visualize the gates of the process and the inspection cycles.
Acceptance Criteria is tied to Product Backlog Items to understand what criteria will be used to determine if a feature on the Product Backlog is completed (or Done). This should be coming from the Product Owner and if these criteria are met by the end of the Sprint, the Product Backlog Items should be considered ”Done”. If other criteria surface during the Sprint, then this would be considered new Product Backlog. Therefore, grooming the Product Backlog before Sprint Planning is important.
Burndown Charts show work remaining over time. Work remaining is the Y axis and time is the X axis. The work remaining typically has ups and downs, but eventually should trend downward. Sprint Burndown Charts give visability to daily progress within a Sprint, and Product Burndown Charts show progress across Sprints toward a Release Goal.
Product Burndown Chart
In Scrum, the Product Burndown Chart is a “big picture” view of a project’s progress. It shows how much work is left to do at the beginning of each Sprint. This chart helps give a sense of accomplishment for the features targeted for a Release. It is an important feedback loop to see early on if you have an acceptable pace toward a Release Goal.
Sprint Burndown Chart
To have a healthy pace and accountability in a project, a Sprint Burndown Chart is a great tool to understand if you can meet the expectations of the Sprint. On ThreeWill projects, we plot our capacity against the burndown. If our projected work in the Sprint is greater than the team’s capacity, this helps flag a potential risk or raises up questions on ways to accomplish the feature in another way (there is always more than one way to build a feature).
These plots are done in a electronic chart or sometimes done manually on a team’s whiteboard. Here is a sample screen shot of a Sprint Burndown Chart (click to see a larger view):
Note that the capacity line in blue and the ETC (Estimated Time to Completion) is plotted in red. The goal is to have the red line below the blue line.
Note that the Y axis represents the estimated work (or capacity) in hours and the X axis is days in the Sprint.
Daily Standup Meeting
A 15-minute or less daily meeting for each team member to answer three questions:
- “What have I done since the last Daily Standup meeting? (i.e. yesterday)”
- “What will I do before the next Daily Standup meeting? (i.e. today)”
- “What prevents me from performing my work as efficiently as possible? (i.e. my impediments)”
The Team Lead ensures that participants stick to the agenda and schedule follow-up meetings for any discussions that go too far outside these constraints.
The Scrum literature recommends that this meeting take place first thing in the morning, as soon as all team members arrive. We make sure this is a mutually agreeable time for geographically dispersed teams.
The Team Lead can elevate any impediments described at the Daily Standup to a Risk that is tracked and managed by the Project Risks List.
When pulling Product Backlog Items into a Sprint during a Sprint Planning Meeting, you need to plan your tasks based on your thoughts about all the steps/tasks necessary to say that you are “done” with the feature. Here are a list of tasks to consider when building out the Sprint Backlog:
- Requirements Clarification and Conversations
- Design Review
- Design Clarification
- Definition of Acceptance Criteria
- Manual Test Definition
- Automated Test Definition
- Development and Configuration
- Deployment to Test/Staging Environment
- Test Execution
- Required Documentation Updated
- Feature Review and Acceptance
- Resolve Defects*
- Feature Updates Post Implementation Review
* If any Defects are not resolved during the Sprint, we capture this as product backlog and schedule it based on the defects priority as it relates to remaining product backlog.
Note that some of the most difficult tasks to manage for a Sprint are the testing activities. Be sure to allocate enough time for testing and that testing activities are scheduled early enough in the Sprint to allow for follow-up development based on the results of the testing. In order to manage testing, Acceptance Criteria should be defined before the Sprint that a Product Backlog Item is implemented. This will allow for properly estimating development and testing time needed to complete the Product Backlog Item.
An Epic is a large User Story and is used as a placeholder for what will eventually be a User Story. Epics are described in the same way as User Stories, but need to be eventually broken down to a User Story before estimating. Typically, Epics are used to capture very high level requirements that need to be visited at a later date by the Team.
Feature Groups are used to organize Product Backlog Items into major components or functional areas.
In the past, we have referred to a Feature Group as a Requirement Area. Also, VersionOne uses the term Theme interchangeably with Feature Group.
- Goals, Themes & Epics: What’s the Difference? - http://community.versionone.com/KnowledgeBase/FAQs/Q11168.aspx
Anything that prevents a Team Member from performing work as efficiently as possible is an impediment. Each Team Member has an opportunity to announce impediments during the Daily Standup Meeting. The Team Lead is charged with ensuring impediments get resolved. Team Leads often arrange sidebar meetings when impediments cannot be resolved on the spot in the Daily Standup Meeting.
- A tester on the project is scheduled to test a feature and there is a bug that does not allow him/her to get to that area of the application.
- The sales guy (Danny) keeps asking me to get involved with Seminars and I have real work to do. Danny is an impediment to the project.
The Product Backlog (or “Backlog”) is the requirements for a system, expressed as a prioritized list of Product Backlog Items. These include both functional and non-functional customer requirements, as well as technical team-generated requirements. While there are multiple inputs to the Product Backlog, it is the sole responsibility of the Product Owner to prioritize the Product Backlog. On ThreeWill projects, the Team Lead will help the Product Owner with this exercise.
Product Backlog Item
In Scrum, a Product Backlog Item (“PBI”, “Backlog Item”, or “Item”) is a unit of work small enough to be completed by a team in one Sprint iteration. Backlog Items are decomposed into one or more Sprint Tasks.
When capturing a Product Backlog Item, you can use a brief description to help the Team remember the item and/or write a User Story.
In Scrum, a single person must have final authority representing the customer’s interest in backlog prioritization and requirements questions. This person must be available to the team at any time, but especially during the Sprint Planning Meeting and the Sprint Review Meeting.
- Defines the features of the product
- Decides on a release date and content
- Responsible for the profitability of the product (ROI)
- Prioritizes features according to the business/market value
- Adjusts features and priority every Sprint (as needed)
- Accepts or rejects work results
Challenges of being a Product Owner:
- Resisting the temptation to add more important work after a Sprint is already in progress.
- Being willing to make hard choices during the Sprint Planning Meeting.
- Balancing the interests of competing stakeholders.
- Coach the Product Owner on their responsibilities
- Team Lead should fill in for the Product Owner when necessary but circle back to make sure the Product Owner was properly represented
There are three essential roles in any ThreeWill Project:
The transition of an increment of potentially shippable product from the development team into routine use by customers. Releases typically happen when one or more Sprints has resulted in the product having enough value to outweigh the cost to deploy it.
Schwaber/Beedle, Agile Software Development with Scrum, p. 80
“The product is released to customer or marketplace obligations. The release balances functionality, cost, and quality requirements against date commitments.”
Setting Release Objectives helps the Team identify items which are in scope for the current release and out of scope. When setting Release Objectives, describe a high level objective or goal for the Feature Groups that comprises a releasable product increment.
Scrum is an iterative, incremental process for developing any product or managing any work. This process for managing complex projects is described by the Scrum Alliance (http://www.scrumalliance.org) and through the following books:
- Agile Project Management with Scrum
- Ken Schwaber
- Microsoft Press, 2004
- ISBN 073561993X
- Agile Software Development with Scrum
- Ken Schwaber, Mike Beedle
- Prentice Hall, 2002
- ISBN 0130676349
An iteration of work during which an increment of product functionality is implemented. Originally Sprints took form in 30 day cycles, but currently our teams use 1 and 2 week cycles (2 weeks for longer term engagements).
The Sprint starts with a Sprint Planning Meeting. After that, Daily Standup Meetings occur during the Sprint (one per day). At the end of the Sprint, there is a Sprint Review Meeting, followed by a Sprint Retrospective Meeting.
During the Sprint, the team must not be interrupted with additional requests. Guaranteeing that the team won’t be interrupted allows it to make real commitments it can be expected to keep. Out of practical necessity, some teams choose to bend this rule by declaring some team members 80% available at the outset so they still have some cycles left for “Priority 1″ bugs and emergencies. But this is a slippery slope and expanding the scope of a Sprint during the Sprint should be avoided whenever possible.
Note that typically a Sprint refers to a Construction Sprint (where the team is building the product), but there are also Planning and Release Sprints. Planning Sprints are to build a Product Backlog and Release Sprints are for transitioning or stabilizing before a release of the product.
Defines the work for a Sprint, represented by the set of Sprint Tasks that must be completed to realize the Sprint Goals, and selected set of Product Backlog Items. The Sprint Backlog is basically a set of tasks, measured in ideal hours, which represent the decomposition of the work required to deliver a given feature.
Scheduling of Sprint Backlog tasks should include time for meetings, conversations, unit test creation, coding etc. — all actions required to deliver the associated feature.
Sprint Goals are the result of a negotiation between the Product Owner and the Team. Scrum focuses on goals that result in demonstrable product. The Product Owner is entitled to expect demonstrable product (however small or simple) starting with the very first Sprint. In iterative development, subsequent Sprints can increase the robustness or size of the feature set.
The Team needs to commit to goals that anyone will be able to see are met (or not met) at the end of the Sprint. At Sprint Review Meetings, the Sprint demonstration is conducted after which the Team asks the Product Owner whether he feels the goals were met.
While some specific Product Backlog Items may not be done at the end of a Sprint, it should be very unusual for a team not to meet its Sprint Goals. Scrum requires the Team to notify the Product Owner as soon as it becomes aware it will not meet its goals.
Meaningful goals are specific and measurable. Instead of “Improve Scalability” try “Handle five times as many users as version 0.8.”
Sprint Planning Meeting
The Sprint Planning Meeting is a negotiation between the Team and the Product Owner about what the Team will do during the next Sprint. The Sprint Planning Meeting is broken into two sessions: a) Review of Product Backlog Features and Priority and b) Sprint Task Planning.
Review Product Backlog Features and Priority
During this session, the Team reviews the product backlog’s high priority items – reviewing enough to fill a Sprint Backlog for the available team resources. The Product Owner and all Team Members agree on a set of Sprint Goals, which is used to determine which Product Backlog Items to commit from the Uncommitted Backlog to the Sprint. Often new backlog items are defined during the meeting. This portion of the Sprint Planning Meeting is time-boxed. Depending on the Sprint Duration this can be 45 minutes to 4 hours. For the typical 2 week Sprint, this is a 2 hour meeting.
Sprint Task Planning
During Sprint Task Planning session, the team will typically excuse the Product Owner from the room and break the Backlog Items down into Tasks. The Product Owner is expected to be on call during this session for renegotiation or to answer questions that affect the time estimates. This portion of the Sprint Planning Meeting is time-boxed to 2 hours. Sometimes teams insert placeholder Tasks (with rough estimates) for the Product Backlog Items they don’t expect to start working until later in the Sprint.
During a Sprint Planning Meeting the Team Members identify and select features from the Product Backlog which equal either their expected Velocity, or their known Velocity from previous Sprints. At the end of the Sprint Planning Meeting the team finalizes the Sprint Goals by which the success of the Sprint is determined. There should be agreement throughout the entire Team. This is not fine grained detail of task by task, but rather the general theme of what will be accomplished for the Sprint.
Sprint Retrospective Meeting
The Sprint Retrospective Meeting is held at the end of every Sprint after the Sprint Review Meeting. The Team and Team Lead meet to discuss what went well and what to improve in the next Sprint. The Product Owner is optional for this meeting.
The Sprint Retrospective should be time-boxed to 1 hour or less.
Sprint Review Meeting
At Sprint Review Meetings, the Sprint demonstration is conducted after which the team asks the Product Owner whether he feels the Sprint Goals were met. A Sprint Review should review and demonstrate each feature’s implementation and update the feature status appropriately (this may vary according to project state transitions features – code complete or complete testing, etc.).
Although a Sprint Review should demonstrate the implementation of each feature pulled into the Sprint, the success of the Sprint should be based on the Sprint Goals. The team reviews and discusses what was successful, unsuccessful and any impediments that should be tracked as Risks in order to improve the overall team process for subsequent Sprints. The Team Lead and the Product Owner update the metrics of the project at the end of each Sprint Review Meeting.
A Sprint Task is a unit of work generally between 4 and 16 hours. Team Members volunteer for tasks. Sprint Tasks are contained by Backlog Items. Scrum literature encourages splitting a task into two or more tasks if the estimate exceeds 12 hours.
Each team member is responsible for updating the remaining work (in hours) for each Sprint task item they own at the end of each day (or before each Daily Standup Meeting. This daily update of remaining hours or Estimated Time to Completion (ETC) is used to plot daily updates to the Sprint Burndown Chart.
Story Points are a relative ranking used for sizing a Product Backlog Item. Story Points are a great way to speed up the process of estimating. You are not looking for the exact hours to achieve a feature, but the relative time it would take compared to other items on the Product Backlog.
Reference for learning Story Points
A great reference for understanding and using Story Points is Mike Cohn’s Agile Estimating and Planning Book. In this book, an entire chapter is dedicated to story points (“Chapter 4 – Estimating Size with Story Points”).
A Story Point is used to estimate the relative complexity of each of the backlog items on a product backlog. At ThreeWill, we use a modified Fibinacci sequence for the estimation scale. This range is 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, and 100. It is a good practice to have estimates that are within one order of magnitude and centered around the scale of 1, 2, 3, 5, 8. Therefore, the team should agree upon what characteristics are attributed to a 1, 3 and 8, so they can calibrate to this area of the scale.
After this calibration is done, the team is ready to start sizing the Product Backlog. Note that these Story Points are a scale of relative complexity, so a 2 is twice as complex as a 1 and a 3 is 1.5x as complex as a 2.
Story Point’s Complexity should roughly correlate with Time to Implement.
A Story Point’s complexity should be on a scale that is relative to the duration of the project (i.e. if the feature appears to be complex to the user but quick to implement and test, then the feature should be ranked as a simple feature due to the ease of implementation… in other words, the complexity is based on the time it takes the team to produce the completed feature).
See Team Member
- Removes the barriers between the Team and the Product Owner so that the Product Owner directly drives Team
- Improves the productivity of the Team in any way possible
- Improves the engineering practices and tools so that each increment of functionality is potentially shippable
- Keeps information about the Team’s progress up to date and visible to all parties
- Represents management to the project
- Responsible for enacting process values and practices
- Removes Impediments
- Ensures that the Team is fully functional and productive
- Enables close cooperation across roles and functions
- Shields the team from external interferences
Many Scrum Practitioners believe that a Team is optimally comprised of 7 plus or minus 2 people. For a ThreeWill Project, teams are typically composed of 2-4 team members from ThreeWill plus 0-3 members from the client.
For software development projects, the team members are usually a mix of software engineers, architects, programmers, analysts, QA experts, testers, UI designers, etc. This is often called “cross-functional project teams”. Agile practices also encourage cross-functional team members.
During a Sprint, the Team self-organizes to meet the Sprint Goals. The team has autonomy to choose how to best meet the goals, and is held responsible for them. The Team Lead (termed ScrumMaster in the Scrum Process) acts as a guardian to ensure that the team is insulated from the Product Owner’s ideas that are really for future features not in scope for the Sprint.
Also, when feasible, it is advisable to put the entire team in one Team Room. This helps break down communication barriers.
A key technique used in Scrum for Sprints. Traditionally the timebox for a Sprint is 30 days. For ThreeWill, we target 2 week Sprints.
Timeboxing Sprints is key to establishing a rhythm for the project. It also helps with evaluating the pace of the project. Having a timeboxed Sprint allows for frequent checks on the Velocity of the team.
Timeboxing is also used for Spikes. This keeps the team from getting into analysis paralysis.
User Stories are used to describe the Feature (requirement) of a system. This is usually in the form of one sentence and it is best to answer the following questions when writing the story:
- Who benefits from the Feature?
- What is the functionality?
- What is the benefit or value of this feature?
Note that a User Story should be used as a reference for conversations around estimating and implementation details.
A measure of a team’s rate of progress; calculated by summing the number of story points assigned to each user story that the team completed during an iteration.
Velocity is used to determine how much Product Backlog effort a team can handle in one Sprint. This can be estimated by viewing previous Sprints, assuming the team composition and Sprint Duration are kept constant. It can also be established on a Sprint-by-Sprint basis, using Commitment Based Planning.
Once established, Velocity can be used to plan projects and forecast release and product completion dates.
Are Velocity Calculations Meaningful?
How can Velocity computations be meaningful when Backlog Item estimates are intentionally rough through the use of Story Points? The law of large numbers tends to average out the roughness of the estimates.
Note that on VersionOne’s support site they mention the following for determining initial velocity (http://community.versionone.com/KnowledgeBase/FAQs/Q10038.aspx):
“Typically teams, when first starting out, will simply use a ratio of 1/3 to 1/2 of the total available hours in signing up for an early iteration in order to account for estimation error, meetings, admin, phone calls, emails, Q&A, etc. (i.e., non-production overhead).”
More details on Velocity can be found on VersionOne’s Site - http://www.versionone.com/Resources/Velocity.asp.