Agile Development
Why Agile Adoption Fails in Some Organizations
SCRUM in Under 10 Minutes (HD) by @hamids

Team Structure
Scrum of Scrums

The Product Owner

The Product Owner speaks to the core team of builders as a single authoritative "voice of value". The Product Owner:

  • owns the Product Backlog - the creation and maintenance of backlog content
  • prioritizes the Product Backlog content by business value and risk
  • helps with coarse-grained estimating
  • answers the teams' questions about requirements
  • owns the Release Plan
  • monitors the progress of work against the Release Plan.

Typically a Product Owner is an experienced Product Manager or Business Analyst. They must be trusted by stakeholders throughout the organization. A good Product Owner must have strong skills in decision making and negotiation. It is critical that the Product Owner be available to quickly respond to questions from the team.

The Builders

Scrum stresses the importance of teams being cross-functional, meaning that the team has all the skills necessary for delivering finished product. This is a key success factor for agile team. Individual members of the team may be a specialists, but the team as a whole is a complete, "cross-functional" team. Team comprise of developers, DBAs, testers.

The builders:

  • estimate cost and communicates trade-offs
  • commit to iteration backlog
  • self-organize and self-manage tasks
  • build each story to completion
  • are responsible for standards and practices

The ScrumMaster

A good ScrumMaster has strong skills in facilitative-leadership. Most teams start out with a dedicated ScrumMaster. Mature organizations may have a single ScrumMaster that serve two separate teams - especially two teams that must be closely coordinated.

The ScrumMaster:

  • knows agile (Scrum) philosophy and practices
  • works to ensure team stays on-process
  • leads as a change agent in the organization
  • protects the team from impediments and distraction
  • facilitates work of Product Owner and Team

External Roles

  • have minimal direct involvement
  • interface with ScrumMaster on issues related to the process
  • interface with Product Owner on issues related to the product.

The team is responsible for providing visibility via status and demonstrations. External people that insist on direct interaction with the team should be recruited as a team member having specific team-responsibilities and sharing in the team's accountability for delivery.

The Process Domain

Agile processes are iterative, incremental, and driven by time-boxed cycles. The rhythm / cadence of the process is crucial. A clockwork flow of guidance and feedback requires incremental planning and delivery.

The Zen of "3-2-1": 3-months, 2-weeks, 1-day
Inspect and Adapt at All Levels in All Cycles: visibility of everything, inspect and assess using measurements and metrics, adaption to synchronize plans and improve process capability.

Iterations are time-boxed to provide:

  • Cadence and Consistency
  • Scope Metering

Cadence and Consistency:

  • Timely feedback requires the measurement of results at regular intervals.
  • Do not vary the length of iteration cycles from one to the next. Variation will severely skew measures.
  • Finish each iteration completely (plan, create, test, document, review, retrospective) even if iteration-scope must be reduced.

Scope Metering:

  • Pull in the amount of work that will fit into the iteration.
  • Do not push more work into an iteration than will fit.
  • Pushing will break the box and break the process.

The Strategic Domain

The "Strategic Domain" is the domain of activity concerned with ensuring return on investment. ROI depends on our ability to manage the delivery of value. Value is identified through the discovery of needs and opportunities. We capture our understanding of value as a catalog of value statements called the "Product Backlog". Each value statement, called a "Story", describes an increment of product value.

The Product Backlog is the tool we use to share knowledge and manage product releases. The Release Plan, which contains a subset of the Product Backlog, guides the development team in transforming value opportunities into product implementation and delivery of value. The understanding provided by the Product Backlog and Release Plan helps us better manage our resources and achieve a greater return on investment. This understanding also helps us set clear expectations with our customers.

The Product Backlog

The Product Backlog is the fundamental tool for effective planning and tracking. The quality of the Product Backlog has a direct impact on the effectiveness of planning and the accuracy of tracking.

The Product Backlog:

  • is owned by the Product Owner
  • catalogs the separate increments of product value
  • prioritized by business value and risk
  • support coarse-grained estimating and planning

A story is a token representing an increment of product capability that is of value to the customer.

User Story

A story is a token representing an increment of product capability that is of value to the customer. It has a short narrative (summary) to remind us what it is about. It is backed up by an understanding of the details. It is a promise for an ongoing, unfolding conversation about the details.

A good fine-grained story:

  • has understandable value to the stakeholders
  • is expressed in stakeholder's terms
  • is understood well enough to be estimated
  • is specific enough to be tested and accepted
  • is able to be completed within an iteration
  • supports verifying coverage of value
  • is independent (withstands change)

Product Planning and Initial Prioritization

  • Larger, higher-level stories (epics) are preferable
  • Well-formed narrative
  • Conditions of satisfaction
  • Valuation - relative customer value, relative business value, penalty costs

Release Planning

Date Driven Planning: How many stories fit into the total number of iterations up to the target date?
Scope Driven Planning: In which iteration does the target story land? What is the end date?

Map out Sprints. Backlog story estimates provide size. Velocity provides iteration capacity. Priority provides relative position of story within backlog. Adjust sequencing to optimize iteration work.

Planning is driven by business needs.

Date-driven needs fix the number of iterations - velocity determine scope.
Scope-driven needs fix the Backlog - velocity determines schedule.

  • Mix of both epic and fine-grained stories
  • Well-formed narrative
  • Relative size estimate
  • Initial sequencing based on relative priority and relative risk

Sprint Planning

  • Epics split into fine-grained stories
  • Story understood by builders and testers
  • Conditions of satisfaction for each story
  • Relative size estimate for each story
  • Relative priority for each story
  • Dependencies and risks identified

Release Burndown

The Release Burndown Chart plots the remaining size-points at the end of each iteration. Running "above the line" indicates that the scope of work will not be completed by the planned end date. Running "below the line" indicates a possibility of finishing early or taking on a larger scope of work than originally planned.

An agile Release Plan is adaptable. When running substantially above or below the line, the plan must be adjusted to reduce scope or change the end date, or possibly do something that could change the team's velocity. Consider adjusting the plan at 1/4, 1/2, and 3/4 of the way through the Release Plan schedule.

Managing the Product Backlogs

This technique is known as "Product Scrum" or "Meta Scrum". Planning at the portfolio and product-strategy levels does not need the same degree of detail as planning the release level. Lower-level backlogs should pull from higher level backlogs. Detail emerges as epics are split into finer-grained stories.

Implementing Agile

Transitioning to a lean and agile approach is a process, not a one-time event. The transition will need ongoing attention and efforts to be successful. An agile transition involves a shift in your team's approach to software development. The team should expect that a transition will take time to realize the most significant benefits, and everyone needs to be committed to working toward success for the long term.

The most successful agile transitions take place when the teams are able to focus exclusively on the agile transition and immerse themselves in the agile practices and a new way of working.


Task burn-down chart

Story burn-down char

Project Community: people that does not involve in the project on a daily basis, but have interest / contribution to the project.

My first hand experience

  • Lunch meeting to size the backlog.

What would I do differently

  • Lookahead Sizing. Rather than just having a separate meeting for sizing the backlog, the team, as part of current iteration, should be informed of what features will be likely be in the next iteration, that way they can do sizing for the next iteration. I often came to the sizing meeting without knowing what will be work on. Features that are complex, and requires a lot of thinking, can't fit into one hour meeting. Even if you have multiple developers on your team, therefore multiple ideas, these ideas are often not quite thought out. When the ScrumMaster send email invitation to the sizing meeting, I suppose that I can look at the backlog, and try to size it, but sizing a complex feature often requires a team effort and discussion, therefore better be done throughout an iteration, rather than in one hour meeting.

Things to remember

  • Agile Development Process build upon the success of other development methodologies (Test First Development, Pair Programming, Extreme Programming)
  • Frequent releases / demos allow for frequent feedback
  • Agile welcome changes in requirement. In the end, you deliver a product with current requirements (happy customer), as supposed to a product with outdated requirements.
  • There is no one right way to implement agile, because agile is flexible to change.


Behind Close Door (book)
Mike Cohn's Scrum Smells



  1. Use wiki to document your code.
  2. Code ownership is bad. Code smells so it is better to have more than one person working on it and improving it.
  3. Big visible chart.
  4. Documentation / bug fix cycle where developers have time to do what he think is important and not tied to a deadline.

Code less, do more. "Do more" includes:

  1. Code review.
  2. Know your product, and think about additional features that would make your product more useful, or user friendly.
  3. Improve the process.

Code review does not always need to be done with a developer. Code review enable you as a manager to know what is being checked into your repository, thus you can detect potential problem (although continuous integration and automated test suites will help, certain things requires human inspection), and response to emergency effectively. At least, it make you look good when your boss ask you about a block of code, and you can answer it.

The tools that you have will affect the ability of your team to produce better product. You should know the limitation of your current tools and look out for new tools that do better job than what you currently have.

planner: a unix utility for project manager

xfig: unix utility for flowchart and diagram


  • Pair Programming
  • Test First Development
  • Extreme Programming
  • Simple and Emergent (Just In Time) Designs
  • Automated Tests
  • Continuous Integration, Automated Builds
  • Frequent, Iterative and Incremental releases

User Stories
Product Backlog
Release Planning
Iteration Planning
Collaborative Working, Co-location, Daily Stand Up (Scrum), Information Radiators
Time-boxed cycles
Retrospective: Inspect and Adapt at All Levels in All Cycles



Travel light, Simplicity, Emergence, Self-organization, Shared vision, Focusing goals, Collaboration, Whole team.
Iterative, Incremental, Frequent delivery, Adaptive Control

Collaborative Working, Co-location, Pairing
Retrospectives (looking back / review), Follow up on retrospectives, Improvement Plan, Continuous Improvement

It is better to slightly under-commit than over-commit. This give developers chance to breath, and think about what need to be done in the future.
Notes that need to be merged into this page

AgileEA (Enterprise Architecture)

More money, more software
On-site customer, video conferencing, online meeting.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License