"Agile software development is about iteration not oscillation"
Jim Highsmith (paraphrased), Agile 2009

"Perhaps the worst software technology of all time was the use of physical lines of code [for metrics]. Continued use of this approach, in the author’s opinion, should be considered professional malpractice."
Capers Jones, Applied Software Measurement

"Deliver frequent, tangible, working results"
Peter Coad

"Kanban is the science of not trying to do too much at once"
Stephen Palmer, 2012

"We try to solve the problem by rushing through the design process so that enough time is left at the end of the project to uncover the errors that were made because we rushed through the design process"
Glenford Myers (via jJeff De Luca)

"I guess that as you go along you try to fill your tool-box, so that when you face these circumstances you have more options to choose from"
Jonny Wilkinson, Tom Fordyce's Blog, 2009

"The structure of a software system will reflect the communication structure of the team that built it."
R. E. Fairley

"When people are factored in, nothing is simple. The complexity of individuals and individuals working in teams raises the noise level for all projects."
Ken Schwaber, Mike Beedle, Agile Software Development with Scrum, 2002

"chaos often results when a project's complexity is greater than its managers' ability to direct meaningful progress toward a goal."
Ken Schwaber, Agile Project Management with Scrum, 2004

"Human brain capacity is more or less fixed, but software complexity grows at least as fast as the square of the size of the program."
Gerald M. Weinberg, Quality Software Management: Volume 1 Systems Thinking, 1992

"The complexity of software is an essential property, not an accidental one. ... Many of the classical problems of developing software products derive from this essential complexity and its nonlinear increases with size."
Frederick P. Brooks, The Mythical Man-Month, 1995

"As the number of people increases, the ways they can interact tend to multiply faster than you can control them."
Gerald M. Weinberg, Quality Software Management: Volume 1 Systems Thinking, 1992

"Use models to find out how things work or to find solutions to puzzling dilemmas. Create models to communicate ideas and understand things you can’t see. Recognize models and the countless ways models are used for working, playing, teaching and explaining. Assess models for what they do and don't tell you about the real thing and how useful they are"
Boston Science Museum

"It usually takes more than three weeks to prepare a good impromptu speech."
Mark Twain

"Simplicity is the final achievement. After one has played a vast quantity of notes and more notes, it is simplicity that emerges as the crowning reward of art."
Frederic Chopin

"If you can't explain it simply, you don't understand it well enough."
Albert Einstein

"Man will occasionally stumble over the truth, but most times he will pick himself up and carry on."
Winston Churchill

"We apply the analytic procedure in order to create a conceptual framework within which we can draw conclusions about the means by which a system solves its tasks. Indeed, we do this with the express purpose of establishing a solid foundation from which we can carry out a subsequent synthesis. This synthesis, in turn, acts to verify the conceptual model as an explanation. The process is an iterative one."
Tom Ritchey, Refactoring, 1991,

"Speech is conveniently located midway between thought and action, where it often substitutes for both."
John Andrew Holmes

"Information Technology is 80% psychology and 20% technology "
Jeff De Luca, www.nebulon.com

What to do with Story Points of Incomplete Stories

Another common question that teams new to Scrum ask is what should they do with the story points of an incomplete User Story at the end of a Sprint?. Should the team be 'credited' with those points or not? In the next Sprint planning should the original number of story points be used or an adjusted estimate that reflects the amount of ork left to do on the story? If a story is carried over and completed in the next sprint, are the team 'credited' with the orignal number of story points or the reduced, adjusted amount for the work done in the second sprint?

When asked questions like this, the first question to ask is why the team is carrying over user stories to the next sprint? This should be exceptional circumstances and not the norm. Encourage the team to be smarter and commit to less, deliver what they say would at the end of the sprint. This is how the game of Scrum should be played. When this is done, the problem simply disappears.

In addition, story points should not really be used as a measure of achievement by a team. Delivery of completed user stories and business value is the goal, not delivery of an estimated number of story points of effort. If teams want to compare achievements, it would make much more sense to compare the business value delivered. This is why story points for incomplete stories are not counted at the end of a sprint, and are not 'credited' to the team in any way.

Story points are primarily there to help a team work out how much they can get done in a sprint. They use the average of what they delivered in previous sprints to calculate how much they believe they can deliver in the next sprint. For this reason, if on rare occasions a story is carried over, the team should be granted the full original story points for the story at the end of the next sprint (assuming they do finish the story this time, of course) so that the average velocity calculation more accurately reflects the teams capacity.

However, during the planning of that sprint, the team should use an adjusted reduced estimate of what is left to be done on any story being carried over, based on the tasks left to complete, to help work out their commitment for that sprint.

In addition, story points are often used to show progress towards goals of a release via a turndown chart. Again, for accuracy, the full story point amount should be used for stories carried over.

The fact is that the overall velocity of the team is not typically limited by the team's ability to write, or even integrate, code. Instead it is gated by the team's ability to understand what specific code they need to write...
Dean Leffingwell, Agile Software Requirements, 2011

Feature-Driven Development

FDD combines key advantages of other agile approaches with model-centric techniques and fluid team organisation. This means that FDD easily scales to much larger teams and projects than generally recommended for other agile approaches. FDD is also characterised by an emphasis on quality throughout the process, and timely, accurate, meaningful status reporting and progress tracking for all levels of leadership.

Domain-Driven Design

Domain-Driven Design comes as a bit of a surprise to those who have been taught that agile software development and especially eXtreme Programming do away with the need for analysis and design techniques like object modeling and notations like the Unified Modeling Language (UML). It is actually very obvious that any software team working in a .Net language, Java, Objective-C, C++ or any of the object-oriented dynamic languages such as Python or Ruby has an object model at the heart of their software.

eXtreme Programming

The premise behind eXtreme Programming is that the cost of making changes to software does not need to grow exponentially more expensive throughout a project or product development life-cycle. That the cost of change does increase exponentially over-time is attributed to unnecessary complexity added early in the project product life-cycle; complexity that provides the flexibility to address all the changes that might be asked for in the future.

Follow me on Twitter...