The Scrum approach to agile software development marks a dramatic departure from waterfall management. Scrum and other agile methods were inspired by its shortcomings. Scrum emphasizes collaboration, functioning software, team self management, and the flexibility to adapt to emerging business realities.
We recently set a team of consultants from my company to conduct a formal assessment of a medium sized financial firm’s an Agile capabilities. I’d like to share thew approach here. The team went on site to conduct interviews and observations in 5 areas –
• Value delivery
• Agile engineering
• Project Management
• Product management
• Environment and Organizational Culture
Also, the investigation took input on the demographics of the individual project being examined, the stakeholders involved and the competitive/regulatory environment in which the organization as a whole operates. Understanding the context in which an organization operates is crucial to understanding the optimal level of Agility, and thus, the plan of action.
Understanding the goals of the organization is particularly important. Not every axis needs to be top-ranked to achieve the company’s goals. In fact, on this particular assessment we found that only one needed urgent attention – Project Management. I’ll provide details in another post.Tags: agile, Agile assessment, Agile Conference 2008, Scrum Basics, Scrum Methodology
There are many variables to estimating the difficulty of a code changes. We could talk about things like the complexity of the code (Cyclomatic Complexity), the experience of the programmers, their familiarity with the topic and/or the specific module, the quality of documentation, etc. It ends up being a fairly subjective estimate. In Scrum teams, story sizes are estimated in relative terms in terms of story points.
The primary benefit to using a technique involving Relative Estimates is that you are asking the team to give you an estimate of difficulty relative to other work that has already been completed. This means that a team can easily give judgments like “This will be twice as hard as that” and come up with functional estimations for predictions without spending a great deal of time coming up with them. Estimates are just subjective guesses anyway, understanding that can be a valuable way to put more time into building something and less time into trying to guess how much time it will be to build it. Planning Poker, also called Scrum poker, is one technique for building relative estimates and for coming to consensus on the effort or relative size of the stories.Tags: agile, scrum backlog, Scrum Methodology, Scrum Sprint Planning, scrum story points, technical debt
When organizations adopt an agile approach to development like Scrum there is so much focus on the iterative nature of agile development that long range vision and strategic product design can get lost. Jimi Fosdick is doing a webinar on November 28 to discuss the need to include long term product vision, coherent user experience and User Centered design and architecture along with specific best practices for achieving a coherent product that delights users.
Topics will include:
• Discussion of Product Vision and approaches to crafting a compelling overall vision for products
• Discussion of User-Centered/Value-Driven design and approaches to incorporating user experience (UX) and software architecture early in the development process
• Explanation of the pitfalls of a lack of vision and so-called “hybrid” models for incorporating UX and architecture into Scrum Projects
You can register for the webinar hereTags: agile, Agile Conference 2008, agile scrum methodology, retrospective meetings, scrum backlog grooming, Scrum Basics, scrum daily standup, Scrum Methodology, scrum sprints, sprint review, The ScrumMaster Role, user stories, user stories and scrum
A pattern I’ve noticed is that Scrum projects are typically managed informally, with the only measures used being various velocity metrics and burndown charts. This may be an issue. Many project managers and executives resist scrum because these only measure the speed of delivery, not the project’s cost or the business value it generates. One of the major differences between traditional and agile projects is that traditional projects focus on delivering software that satisfies requirements, while agile projects focus on maximizing ROI through continuous feedback and re-planning.
This is where Earned Business Value calculations come in. It fits well with Agile projects, since the focus of agile projects is on business value rather than conformance to requirements (outcomes over outputs). In many cases, EVM metrics are easier to calculate and understand in agile environments than in traditional ones. There are three key management measures – Cost Performance Index (CPI), Schedule Performance Index (SPI), and Earned Business Value (EBV) – that provide information to help manage an agile project from and ROI perspective.
There is a solid white paper on this topic at .
I’d also be very interested in your comments to this post.Tags: agile, Agile Conference 2008, agile scrum methodology, CSM Exam, Danube, Earned Business Value, EBC, product owner scrum, retrospective meetings, scrum backlog, Scrum Basics, scrum daily standup, scrum effort estimation, Scrum Methodology, scrum story points, sprint review, sprint review meetings, The ScrumMaster Role
When you think of the word “habit” what do you think of? In the dictionary, there are several distinctly different meanings for “habit” such as:
1. A customary practice or use
2. An acquired behavior pattern regularly followed until it has become almost involuntary
3. An addiction, especially to narcotics
4. A dominant or regular disposition or tendency; prevailing character or quality
We tend to think of “good” habits or “bad” habits. When the behavior we are repeating results in positive circumstances, it is “good”. When it leads to negative results, addictions etc. it is “bad”.
The “daily scrum” is the heartbeat of scrum and is a “good habit”. Tamara Sulaiman, a Certified Scrum Trainer, in her blog post titled “Techniques for Improving Your Daily Scrum; when Your Daily Scrum isn’t Daily” says, “The daily scrum is one of the most valuable practices that any team can use.” The purpose of the daily scrum is to increase the team’s communication and focus by answering 3 questions, “What have I accomplished since the last meeting? What do I plan to do for the next meeting? What impediments are in my way? “ When teams don’t huddle daily, they risk losing the communication, focus and momentum of a team necessary to build the right product with the appropriate quality on time. Oftentimes, teams will have excuses for avoiding the daily scrum or stand up meetings. I’m sure you will be familiar with many of the excuses Tamara talks about. The daily scrum, however, makes teams more successful because it is the smallest, tightest feedback loop built into the Scrum framework. Think of it like brushing your teeth or exercising daily– it’s a good daily habit to make and will pay off in the long haul.
Scrum teams know that velocity is a rough estimate for the amount of work that a team can accomplish in a given sprint. It is calculated by simply adding up all the completed story points. Since the point values are merely estimates of the perceived difficulty and time necessary to complete the backlog item, a team’s velocity is not especially useful in and of itself. Instead, it becomes a valuable metric over time as teams complete multiple sprints and have the opportunity to establish a consistent velocity. Once this occurs, the Product Owner can look to the team’s established velocity to determine how much work it can tackle in the next sprint.
Amr Elssamadisy has just posted on the topic of velocity and concludes his post with the following questions: “Should velocity be used a metric for productivity? Should it be used for iteration planning? What about longer term release planning? Should it be used at all, or is it a wasteful practice?”
As always, I’m curious to hear how you’d answer those questions, so please share your thoughts in the comments section.
As you might guess, I’m of the mind that tracking velocity is a valuable process. However, the limits of its value must be understood, since it is derived from estimates (i.e. abstracted valuations) and not an absolute indication of progress or productivity. Thus, it can be helpful for sprint and release planning, but should be regarded as an estimate all the same.Perhaps the most valuable aspect of tracking velocity is the ability to observe how a team develops over time. That is, if a team consistently increases its velocity, it can be inferred that the team is learning to work together better and incrementally improving its performance.
To see an example of a team computing velocity, pay attention about halfway through this example Sprint Review Meeting.Tags: Scrum Methodology, Scrum Sprint Planning
Posted by admin under Scrum Basics
There are three roles in the Scrum method of agile software development: the Product Owner, the ScrumMaster, and the team.
In Scrum, the Product Owner is the one person responsible for a project’s success. The Product Owner leads the development effort by conveying his or her vision to the team, outlining work in the Product Backlog, and prioritizing it based on business value. Of course, he or she must also consider the stakeholders and the team. As such, the Product Owner must be available to the team to answer questions and deliver direction.
This combination of authority and availability to the development team makes it hard for the Scrum Product Owner not to micro-manage. Scrum values self-organization and, as a result, the Product Owner must respect the team’s ability to create its own plan of action. This means that a Product Owner is forbidden to give the team more work in the middle of the sprint. Even if requirements change or a rival organization unveils a new product that renders the team’s work all for naught, the Scrum Product Owner is discouraged from altering the sprint until the next sprint planning meeting. However, the Product Owner may cancel a Sprint when necessary. One Product Owner I know cancels Sprints once or twice per year tops.
It is the Product Owner’s responsibility to consider which activities will produce the most business value. This means making tough decisions—that the team might not appreciate—during sprint planning. However, the Product Owner is the one person who must face the music if the project crashes and burns. Therefore, he or she must aggressively determine which features of a product are most important, when they are developed, etc. Just as the development team must produce the negotiated work for the Product Owner, the Product Owner must deliver the product to the customer.
The responsibilities of the Product Owner are also described about halfway through this video module:
Posted by admin under Scrum Basics
In Scrum, the product backlog is the single most important artifact. The product backlog is, in essence, an incredibly detailed analysis document, which outlines every requirement for a system, project, or product. In simpler terms, it could be described as a comprehensive to-do list, expressed in priority order based on the business value each piece of work will generate. Philosophically, the scrum backlog is the engine of the business; it breaks the big-picture story down into manageable increments of work called Product Backlog Items (PBIs).
When the sprint planning meeting occurs, the Scrum team converses with the Product Owner to determine what work they will tackle in the impending iteration. At this time, the Product Owner imports PBIs from the into the sprint backlog.
Now, you may be wondering what a backlog looks like. The answer to that rests on whether a Scrum team uses manual agile or an agile tool to track progress. With manual agile, a team would create a physical manifestation of the backlog, using a dry erase board, Post It notes, or a taskboard. This is ideal for teams that work in closely proximity, whether the same office or room. In this setting, every team member has easy access to the product backlog, the sprint backlog, and the status of its stories; they can simply get up from their desks and walk over to them.
When Scrum teams are not collocated, however, they often require a tool to help them all stay on the same page. There are numerous tools designed to bring geographically distributed teams together using a virtual taskboard. Danube publishes ScrumWorks® Pro, a Scrum management tool that gives users a Web-based task management interface that mimics the look and feel of a physical taskboard. The tool also offers more detailed views of the product and sprint backlogs, organized in adjacent panes and easily modified with drag-and-drop prioritization.
Although it is the team’s responsibility for completing the work, the Product Owner is the only one who can prioritize work in the scrum backlog or, after negotiating with the team, add work to the sprint backlog.Tags: backlog items, scrum backlog, scrum backlog items, Scrum Methodology, scrum PBIs
Posted by admin under Scrum Basics
While backlog refinement (also called grooming) was not originally a formal meeting in the Scrum framework, Ken Schwaber, who founded Scrum, advises teams to dedicate five percent of every sprint to this activity. As with Scrum’s other meetings, the grooming should take place at the same time and place and for the same duration each sprint.
Everyone attends the backlog refinement meeting: the team, the Product Owner, and the ScrumMaster. During the meeting, everyone helps prepare the Product Backlog for the sprint planning meeting. This usually includes adding new stories and epics, extracting stories from existing epics, and estimating effort for existing stories. Why is this helpful? Because a groomed backlog will help streamline sprint planning meetings; otherwise, they can stretch on for hours. When product backlog items contain clearly defined acceptance criteria and are estimated by the team members, the planning process does not have to be tense or overly long. By dedicating a time to backlog maintenance, the team ensures that this preliminary planning occurs prior to the sprint planning meeting.backlog grooming, scrum backlog, scrum backlog grooming, Scrum Methodology
Posted by admin under Scrum Basics
Sprint Planning Meeting
In Scrum, every iteration begins with the sprint planning meeting. At this meeting, the Product Owner and the team negotiate which stories a team will tackle that sprint. Time-boxed to four hours, this meeting is a conversation between the Product Owner and the team. That is, it’s up to the Product Owner to decide which stories are of the highest priority to the release and which will generate the highest business value, but the team has the power to push back and voice concerns or impediments. This is a good thing since the team may be aware of a legitimate impediment keeping the team from moving forward.
When the team agrees to tackle the work, the Product Owner adds the corresponding stories into the sprint backlog. We usually recommend this be physically represented by moving a Post-It note or index card with a story written on it from the backlog into the sprint backlog. If a team uses an agile tooling solution, this might be represented in a number of ways. A tool my company uses, ScrumWorks® Pro, has a two-paned view of a project, in which the product backlog appears on the right and the sprint backlog on the left. Using an intuitive, drag-and-drop interface, the Product Owner can easily add stories to the sprint.
At this point, the Product Owner may choose to leave while the team decomposes the sprint backlog items into tasks, though he or she is still expected to be available to answer questions, clarify Product Backlog Items, or renegotiate. This meeting, which was previously called the sprint definition meeting, is also time-boxed to four hours to limit all sprint planning activities to a single day’s time.
Now that sprint goals are defined, the team is ready to get to work. Of course, other meetings also happen during the sprint, which I’ll discuss.
The Daily Standup
The heart of the Scrum process is the daily standup meeting, also known as the daily Scrum. This meeting helps ensure that the entire development team is always on the same page. Every day, the Scrum team gathers together, usually in a team room or private office—to report on the progress made since the last meeting, goals for the next one, and any impediments blocking their path. These reports are often phrased as responses to the following three questions:
- What have I done since the last Scrum meeting (yesterday)?
- What will I do before the next Scrum meeting (tomorrow)?
- What prevents me from performing my work as well as possible?
This meeting should not exceed 15 minutes. If members of the team need to discuss an issue that cannot be covered in that amount of time, it is recommended they attend a “sidebar” meeting following the standup. This allows team members to attend meetings that directly involve their work, instead of sitting through irrelevant meetings. Unfortunately, daily Scrums often last longer than 15 minutes. To compensate, many teams use stop watches or timers to uphold the time limitations. Also, to limit distracting small talk, many teams employ a talking stick or mascot, which a team member must hold to speak in the meeting. Upon finishing an update, the talking stick is then passed to the next team member, who reports, and so on.
When the daily Scrum meeting is held is for the team and Product Owner to decide, but most Scrum literature encourages teams to hold the meeting as soon as all the team members arrive in the morning.
Sprint Review and Retrospective Meetings
When the sprint ends, it’s time for the team to present its work to the Product Owner. This is known as the sprint review meeting. At this time, the Product Owner asks the team to demonstrate a potentially shippable product increment. The Product Owner declares which items are truly done or not. Teams commonly discover that a story’s final touches often excise the most effort and time. Partially done work should not be called “done.”
After the sprint review meeting, the team and the ScrumMaster get together for the retrospective meeting. During this meeting, the team considers what went well, what didn’t, and what improvements could be made in the next sprint. Team members should be able to speak frankly about the sprint’s successes and failures. It’s an especially important opportunity for the team to focus on its effectiveness and identify strategies to improve its processes. Moreover, it allows the ScrumMaster to observe common impediments that impact the team and then work to resolve them.
Tags: retrospective meetings, scrum daily standup, scrum meetings, Scrum Methodology, scrum retrospective meeting, scrum sprint planning meeting, scrum sprint review, sprint review, sprint review meetings
Scrum Training Series
- Scrum based funding model – 20 percent May 9, 2013
- The Next Big Idea March 5, 2013
- On Being Available February 17, 2013
- Should Scrum Always Require the Product Owner to Attend the Sprint Retrospective Meeting? February 5, 2013
- Happiness Metrics January 23, 2013