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.

21st
NOV

Scrum Effort Estimation and Story Points

Posted by admin under Scrum Basics

Anxiety about estimation usually means the organization is not strong in the other Agile practices such as Test Driven Development (TDD). Scrum requires that the product be kept in a potentially shippable (e.g. properly tested/integrated) state every Sprint, that the Product Owner declares which work is top priority, and that work be split into thin vertical slices, typically customer-centric user stories no bigger than a few days each. If we’re doing the other Agile stuff right, we cannot miss release dates because the product is shippable every week or two. The only downside of getting estimates wrong is that we’ll ship on time while omitting the less important features — a less stressful way to live than what waterfall or pseudo-Agile teams are experiencing today.

In waterfall, managers determine a team member’s workload capacity in terms of time. Managers ask selected developers to estimate how long they anticipate certain tasks will take and then assign work based on that team member’s total available time. In waterfall, tests are done after coding by specific job titles rather than written in conjunction with the code. The downsides of waterfall are well known: work is always late, there are always quality problems, some people are always waiting for other people, and there’s always a last minute crunch to meet the deadline.

Scrum teams take a radically different approach. First of all, entire Scrum teams, rather than individuals, take on the work. The whole team is responsible for each Product Backlog Item. The whole team is responsible for a tested product. There’s no “my work” vs. “your work.” So we focus on collective effort per Product Backlog Item rather than individual effort per task. Second, Scrum teams prefer to compare items to each other, or estimate them in relative units rather than absolute time units. (Ultimately this produces better forecasts.) Thirdly, Scrum teams break customer-visible requirements into the smallest possible stories, reducing risk dramatically. When there’s too much work for 7 people, we organize into feature teams to eliminate dependencies.

What does the process of estimation look like? Scrum does not prescribe a single way for teams to estimate their work. The only estimate that’s defined by Scrum is whether a team will attempt a PBI this Sprint or not, as decided in the Sprint Planning Meeting. Common estimating methods include t-shirt sizes (S, M, L, and too big), powers of 2 (1, 2, 4, 8), the Fibonacci sequence (1, 2, 3, 5, 8, etc.), or simply small vs. needs-to-be-split (see #NoEstimates below).

In the Backlog Refinement Meeting, the team sits down with the Product Owner to discuss the stories toward the top of the Product Backlog. The Product Owner often wants effort estimates to help evaluate ROI, effectively prioritize items in the Product Backlog, and predict which items will be ready by a given release date. So the Product Owner wants an honest appraisal of how difficult work will be.

To gather a cross section of viewpoints despite the different personalities on a team, it is often useful for all team members to disclose their estimates simultaneously. Individuals show their cards at once, inspiring the term “planning poker.” Individuals will usually choose different cards. This should trigger discussion of the implementation approach, clarification of the requirement with the Product Owner, and splitting the requirement into smaller stories (some of which will be lower priority). Often several rounds are necessary to arrive at a single effort estimation that reflects the entire team’s sense of a story’s difficulty. The refinement and clarification are more important than the estimates themselves. According to the Agile Manifesto, business people and developers must work together daily throughout the project.

#NoEstimates Controversy

In recent years, teams subscribing to the #NoEstimates philosophy have simply made all stories as small as possible. For #NoEstimates teams, the only estimate is whether a User Story is small. If it’s not small, they split it until it is small. Some of these teams still make forecasts by comparing completed stories over time to stories remaining in the release plan. The #NoEstimates approaches are gaining ground, but not universally accepted within the Agile movement.

Interfacing With Traditional Expectations

For techniques that may be more palatable to traditional managers, see Mike Cohn’s popular book Agile Estimating & Planning. Our own team used some of these approaches to make multi-month forecasts and release plans. They were still a bit off, but they were closer than anything I’d seen before. One thing that helped was doing everything possible to eliminate unnecessary unpredictability. Product development is ultimately about learning and creating, so some unpredictability is necessary. But unnecessary unpredictability can often be reduced by keeping the same team together, keeping the Sprint length the same, always building end-to-end integrated vertical slices, eliminating external dependencies, and using techniques like TDD to avoid surprise regression failures and interruptions. Bad code causes painfully unnecessary unpredictability in waterfall or Agile.

If you’re wondering how to make all this work with contracts, I’d urge you and your lawyers to read the Agile Contracts Primer.

About The Author

This article was rewritten by Michael James, an Agile coach based in Seattle (but often found in other cities). Follow MJ on Twitter or LinkedIn.

Examples

Need an example? Watch an example team conduct a Backlog Grooming Meeting, including relative estimation and example user stories. Planning poker is demonstrated at the 4 minute mark of this video:

 
To see how velocity is computed from story points, watch an example Sprint Review Meeting including velocity measurement.
 

Tags: , , ,

17th
FEB

On Being Available

Posted by ewok_bbq under transformation, Uncategorized

One of the things I am thinking about and working on is the concept of being more available.

Over dinner, in Tokyo at the regional Scrum Gathering Cope,Julia, Kotaro and I had a great conversation. The premise was on the old saying, “you are either cheap or available.”   Basically, the concept is that if you or your services are cheap, then you are never available.  If however, you are available, then indeed you are expensive and valuable.
Emmanuel Lévinas[1] (French pronunciation: ​[emanɥɛl levinas];[2] 12 January 1906 – 25 December 1995) was a French philosopher and Talmudic commentator of Lithuanian Jewish origin.

Emmanuel Lévinas[1] (French pronunciation: ​[emanɥɛl levinas];[2] 12 January 1906 – 25 December 1995) was a French philosopher and Talmudic commentator of Lithuanian Jewish origin.

When I brought up to Cope that we need to be available he said that when he was with customers he was more than available.  Probably going back to some Emmanuel Lévinas theory of “the responsibility to the Other” Copewants to become one with his customers, to eliminate the a priori  instinct to separate the ‘us vs. them’ and to take on the being of his customers.  He can only do that when he assumes their organizational identity.  And once assumed he is totally emerged into being more than available.  I am sure his customers have benefited greatly from that.  More so then a conf. call from 5,000 miles away trying to spit advise into an unknown situation.
All to often over the past few years I haven’t prioritized my own work life around being available to those that matter most.  Looking back on it, I have, unfortunately, lived an interruption driven work life.  While running Danube, I was usually being interrupted by the crisis of the day or I was under the daily financial stresses.  It didn’t feel great.  Today – I probably take too many phone calls and am in too many conversations that don’t matter that much.  In addition, it’s easy to fool myself into thinking that I am adding value to meetings and conversation threads where my opinions are neither valued or innovative.   For an alternative, maybe I should try what Jurgen Apello does (could any one else get away with this?)
The side effect of being less available is that I can’t do what I want or need to do (e.g. being in a state of flow) or that I push off meaningful, yet less urgent conversations or thoughts, to tomorrow knowing that very well tomorrow may never come.
This year I think I am going to make a promise to myself to do less, but be more available to the customers, employees and friends that matter most. I will give more of myself to less things in an effort.
Is this just wishful thinking? What do you think? I would love to hear from you.
Tags: ,

12th
DEC

Complexity and cost of change

Posted by admin under Agile and Scrum, Scrum Basics, Scrum Discussion

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: , , , , ,

3rd
NOV

Agile and PPM – Q&A

Posted by admin under Agile and Scrum, Agile Manifesto, Agile Principles, Scrum Basics, Scrum Discussion, Scrum Transitions

The webinar, “A Marriage Made in Heaven: Agile and Project Portfolio Management,” took place on October 27. I (David Parker) hosted, along with Russ King, Vice President, Product Development, Results Positive, Inc. and Caleb Brown, Systems Engineer at CollabNet. During this session, we explored the benefits of marrying Agile Project Management and PPM and we did a live demo showing this using HP’s PPM solution and CollabNet’s ScrumWorks Pro to demonstrate the powerful capabilities of managing a resource constrained project portfolio.

If you’re interested, you can watch the recording and download my slides. Here, I post some of the questions and our answers:

Q: How feasible is Agile on Projects & Programs?
A: Agile is typically thought of in the context of individual projects. Companies sometimes fail to scale that paradigm to a program level, where the program is a superset of multiple projects, each running its own lifecycle and release plan. The trick is to weave those separate lines of development (projects) into a coherent and seamless deliverable (program). The complexity comes in gathering meaningful metrics and planning releases that thread the elements together. This is exceedingly difficult to do manually. CollabNet’s ScrumWorks Pro is a tool that can make this manageable. It supports the planning of complex releases that weave in multiple development threads.

Q: Will this process will be feasible for maintenance related projects (Incident handling, less than 8 hours development works, etc.,)?
A: From the PPM perspective, an individual defect is not in and of itself a project and as such, would not be tracked. What might be tracked is a larger group of maintenance items in the form of an Epic. From an Agile perspective, a bug report or defect is just another piece of deliverable business value, like a User Story or any other Product Backlog Item. From a bug report, the product owner and team would create a Product Backlog Item (PBI), along with success criteria (definition of done). It is prioritized against all of the other Product Backlog Item by the product owner. Again, multiple bugs/defects are often grouped in an Epic.

Q: It seems the PPM is geared toward a waterfall process. It appears there is only visibility into the Development phase, but with agile, you could potentially address all phases within a single sprint. Is that just because of the way this implementation was set up or is it there isn’t a true marriage of the agile within PPM?
A: PPM in this scenario is focused on evaluating the ROI of different projects and deciding where to make investments. Agile is focused on execution of the projects that are chosen. That said, the scenario we propose makes the entire organization more Agile, in that the feedback loop is instantaneous. This allows those that are making the investment decisions to adapt and make course corrections that are indicated by that feedback loop. The integration gives all team members the ability to work in a more Agile fashion, and gives Stakeholders and Project managers the ability to benefit from the faster feedback and data generated by the team working this way.

Q: Can the tasks in Scrum WorksPro be connected to tasks, timelines in Source forge?
A: Not with Sourceforge. However this is possible with Collabnet Teamforge, the current commercial version of Sourceforge.

Q: Can you clarify what part of Agile PPM can be done in scrum works pro without need for HP PPM?
A: ScrumWorks Pro is focused on project execution and project management. As such ScrumWorks does a number of things not accomplished in HP PPM. These include PBI tracking and prioritization, Task management sprint planning, release planning, team velocity, forecasting, and many other functions related to the management of an Agile project.

Q: So are you proposing (in the demo) to combine a phase/waterfall planning and design phase, but then execute in an agile framework?
A: Combining HP PPM and ScrumWorks Pro adds to the agility of the entire organization. Feedback loops between the development team and the PMO are enhanced allowing the PMO to make course corrections required. I would not say that as a result the entire enterprise has become agile – only that they’ve become more agile. Generally, we do not see many organizations that practice a pure version of ANY methodology –be it Agile or otherwise. The reality is that organizations have a mix of methodologies, like Scrum, Kanban, Waterfall, hybrids, etc. Different teams in large organizations will often build software differently, so the challenge is to roll up the data from those disparate teams. Despite their differences, there are a number of common metrics you can track regardless of project type. These include actual cost versus budgeted cost, scope change, personnel/resource change, delivery dates, and others. Tools like ScrumWorks and HP PPM do a good job in tracking these kinds of numbers.

Q: Continuing from the first question, from a portfolio perspective, having “”open-ended”” project budgets within the Agile/SDLC process is not in the best interest of my customer. How does budget planning and Agile development work together while still having some control over costs?
A: Project prioritization and the associated budgeting/funding are is under the purview of the PPM tools. The agile project management tool tracks the amount of time individuals spend on the project. The integration between the HP PPM tool and the Agile Project Management tool, allows you to easily compare budgets against actuals.

Q: For the Forecast report in SWP, if new backlog items are added during the sprint, does that add to the top or bottom of the bar? Also, how does the Project Portfolio Management tool fit into the larger Enterprise Architecture discipline?
A: It depends on what report you are looking at. In the forecast report, added backlog item appears on the bottom of the report and impacts the forecasted delivery date.
Forecast report

The “Burn-Up” Report shows the relationship between work completed per iteration (sprint velocity) and project scope change. The forecast feature extrapolates the rate work gets done against the rate of scope change to provide an empirical release completion forecast for more accurate release planning.

Burn Up Report

Q: In agile, what are the differences between being adaptive to late changes in requirements within a sprint and scope change?
A: Scope change refers to any added or subtracted scope, typically measured in some form of relative effort unit like Story Points. As such, scope may be added as a team discovers more about an existing requirement. In other words, if the team finds out that a requirement is more complex than was originally envisioned, they may re-estimate the number of story points and this might add scope to a sprint. The opposite could also be true. Whether this occurs because of a discovery inside a sprint or outside of it doesn’t change the nature of how it is tracked or reported upon.

Q: When a committed backlog item could not be completed in a sprint, naturally it holds the top most priority in the following sprint. How does ScrumWorks helps in tracking this item from the beginning to end?
A: An unfinished PBI may or may not be a high enough priority in a future sprint. The determination is made by the product owners. In any event, any activity against that PBI is tracked. Tasks completed that relate to that PBI are tracked, as are those that were uncompleted.

Q: What certification do CollabNet-trained scrum masters receive?
A: Those who attend one of our Certified ScrumMaster or Certified Product Owner training are eligible to take the exam deliver by the Scrum Alliance. It should be noted that CollabNet is one of the leaders in ScrumMaster product Owner training. We have more Certified Scrum Trainers on staff than any other vendor, and we’ve trained more than 12,000 ScrumMasters.

Q: If an organization wants to be able to report a metric of time to resolution for individual PBIs, what settings are available in this integration to include/exclude a PBI from the current active lists so that a countdown starts appropriately?
A: Forecast reports in ScrumWorks can be filtered on any number of aspects, allowing a user to deliver estimates on individual tasks, Stories, Epics or Themes. By the way, you can try out ScrumWorks Pro either in a hosted environment or as a free download.

Tags: , , , , , , , , ,

13th
OCT

Building the Product Backlog

Posted by admin under Agile and Scrum, Scrum Basics, Uncategorized

Building and maintaining a Product Backlog can be a time-consuming effort. Though the Product Owner has final say in the prioritization, a good product backlog is a result of a combined effort of the entire team – Product Owner, Scrum team, ScrumMaster and stakeholders.

One expert in this area is CollabNet Certified Scrum Trainer Angela Druckman. Ms. Druckman will be hosting a webinar focusing on techniques and ideas for improving the overall effectiveness of backlog management.

The webinar will be held on Monday October 27, 2011 at 11:00 am pacific time. You can register here:

21st
DEC

ScrumMaster as Impediment

Posted by admin under Agile and Scrum, Scrum Basics

One of the biggest reasons the Scrum framework works so well is through the role of the ScrumMaster, an individual whose time is dedicated to ensuring a team’s ability to deliver on its sprint promises remains unobstructed. The ScrumMaster achieves this in a number of ways, such as by reminding the team to adhere to the Scrum process and keeping the Product Owner informed about how development is going. But, above all, the ScrumMaster is charged with removing impediments that prevent a team from completing the work it has negotiated for a given sprint. This can literally be anything from replacing a broken PC to mediating a disagreement between two developers. If it’s keeping the team from moving forward, it’s the ScrumMaster’s job to eliminate the impediment.

But what about situations when the ScrumMaster is the impediment? As Vikas Hazrati of InfoQ observes, it’s a scenario faced by many Scrum and agile teams, especially offshore installations where cultural hierarchy and traditional communication strategies complicate the process even further. But, as many CSTs have countered, when the ScrumMaster is creating an additional impediment for the team, there’s likely a greater degree of dysfunction lurking elsewhere that is manifesting itself in the ScrumMaster role. Usually, it means that traditional, command-and-control management techniques are still dominating the organization, even if the outward effort is to become more agile or abide by the rules of Scrum. For instance, if the ScrumMaster is committing to work on behalf of the team, acting as a proxy for the Product Owner, or actively managing the team (instead of respecting the ScrumMaster role’s lack of authority), Scrum’s distribution of authority and responsibilities are being broken. And when that happens, Scrum’s potential to deliver value is undermined, as well.

Do you encounter ScrumMasters at your organization who seem to do the opposite of what their role demands? If so, what are the reasons you suspect these ScrumMasters are failing to remove impediments, etc.? Please share your thoughts in the comments section.

Tags:

11th
DEC

Advice for Agile Adoption

Posted by admin under Agile and Scrum, Scrum Transitions

One of the most common refrains in the agile and Scrum industry is that implementing those new processes is both hard and disruptive. By now, no one should be surprised to find out that there’s pain in changing—especially in situations in which groups of people are asked to dramatically revise the way they’ve always worked. But in an InfoQ story by Vikas Hazrati, Dave Nicolette reveals his experiences with Scrum and agile adoption, which suggest that a successful transformation is even harder than we all thought.

Many consider the creation of a single, functioning Scrum pilot team to be the big hump to get over during initial implementation. But according to Nicolette, that doesn’t necessarily mean an organization is out of the woods. As he explains, it’s not uncommon for a pilot team to be broken up to begin additional teams, which can often undermine the chemistry of the original team and fail to translate throughout the organization. In other scenarios, a pilot team may simply revert to old habits as soon as an on-site consultant leaves.

In Nicolette’s view, the two main reasons that pilots fail to stick at an organization are:

That’s some good food for thought—and possibly a way to help your pilot team lead the entire organization toward a successful Scrum or agile adoption.

Tags:

16th
OCT

Danube’s New Scrum Video Blogs

Posted by admin under Agile and Scrum, Scrum Basics

I’ve mentioned here before that my team uses Danube Technologies’ ScrumWorks Pro to manage development efforts. Since Danube is a Scrum company, I check their site frequently for new content written by its team of Certified Scrum Trainers, which includes blogs, white papers, and more. When I visited the site yesterday, I was happy to discover that the company has launched a new video blog series, which gives folks a chance to watch a short clip of a CST discussing an issue related to Scrum. The first installment features Jimi Fosdick, who starts the conversation by asking, “What Is Scrum?” So far, the company has only posted one video, but I’m excited to see where this goes. It already looks like a great resource for Scrum users learning the ropes. Check it out here.

Tags: , ,

14th
SEP

Back to Scrum Basics: Product Backlog Items vs. Tasks

Posted by admin under Uncategorized

The Product Backlog is a force-ranked list of Product Backlog Items (PBIs), which should represent customer-centric product features. The Product Backlog should not contain tasks.

Since it is the Product Owner’s responsibility to determine what work will yield the most business value, the Product Owner prioritizes the PBIs. The Product Owner focuses more on the “what,” while the “how” is left for the team to decide.

The Product Owner and team should collaborate about an hour per week on backlog refinement (aka “backlog grooming”) to convert large fuzzy requirements (“epics”) into more distinct user stories. If a PBI would take more than a quarter of a two-week Sprint, it’s probably too big.

Only a subset of these PBIs, the Sprint Backlog, are tackled by the team in a given Sprint. During Sprint Planning, and during the Sprint itself, the team discovers and tracks the Sprint Tasks necessary to accomplish each PBI in the Sprint Backlog. I often meet teams that cannot distinguish their Sprint Backlog from their Product Backlog, making me wonder whether they have clear goals.

My favorite way to keep track of Sprint Tasks is with a physical taskboard, owned by the team. The team is less likely to self manage if people outside the team, including the Product Owner, try to scrutinize their progress during the Sprint, particularly at the Task level. The demo at the Sprint Review Meeting is a more appropriate time to inspect and adapt the product.

If the effort to accomplish PBIs is estimated, we prefer relative units such as T-shirt sizes or Story Points—i.e. abstracted estimates of difficulty. Sprint Tasks should usually take one day or less. Some teams find it useful to estimate Sprint Tasks in hours, though we eventually stopped estimating them at all. Also, there’s no point in trying to reconcile the effort estimates of PBIs and Sprint Tasks.

 

Watch a team break Product Backlog Items (PBIs, or User Stories) into Sprint Tasks during the Sprint Planning Meeting.

 

Tags: , ,

29th
JUL

Scrum Users Group Update

Posted by admin under Uncategorized

If you missed our original post on this topic, InfoQ has published a follow-up to the Scrum Users Group controversy here. After the Scrum Alliance issued a notification to Scrum users group nationwide that it held rights to the use of the phrase “Scrum users group,” a wave of confusion ensued. The Alliance’s Cory Foy weighed in on our comments section to better explain what was happening. It seems that Foy has now been appointed “community liaison” and will interface with the various users groups to help Scrum continue to flourish on a grassroots level. Key to this outreach effort is an inclusive mailing list to get the word out about events and groups, while generally fostering a dialogue focused on Scrum. Sounds like the situation’s definitely improving, but InfoQ reporter Mark Levison still concludes his article by wondering if anything’s really changed.

This seems like a step in the right direction to me. What do you think?

Tags:

Scrum Training Courses