Lean & Agile

Lean and Agile is the philosophy and toolkit to continuously enhance the customer value of your products, to improve the way you make them and to develop your team members, taking a long term view.

Agile Practices

Every organization can elaborate their own adequate version of Lean and Agile Project Management. Yet some characteristics are quite common. Lean and Agile Project Management are in fact a proven process for project management, after eliminating lots of waste from traditional project management. This leads to a project management process which makes things right the first time, promotes working in teams and in single piece flow, avoids handovers, startup time and over-processing on the planning process itself.

Lean and Agile Project Management succeeds in doing that, by working on one project at a time and by slicing up big chunks into smaller bits: Both of time frames and of products. Then, it's also about having life meetings with living people, rather than using email and written reports (User Story Meetings, Daily Stand-up Meetings, Iteration Meetings and Release Meetings). And it's about using intuitive tools, rather than calculating everything (User Stories, Planning Poker, Priorities, Team Velocity).

Slicing Up Timeframes

Project timeframes are sliced into Releases, Iterations and Days. Releases are relatively longer periods to complete a first, second or nth version of a product. Upon conclusion of a release the project may be stopped for a while, or enter a new Release straight away. Releases are split into Iterations. Iterations are relatively shorter intervals, meant to finish smaller amounts of work. Days are simply working days, when the team is working on a project.

Slicing Products

Products are sliced into Themes, User stories and Tasks. Themes must be completed during a Release and are composed of several different User stories. User stories must be completed during an iteration and need to be done by different team members. Tasks are individually assigned to one team member only. It should be possible to complete most tasks within a day.

User Story Meetings

The user story meeting is a meeting with clients, stakeholders (including user proxies) and the production team where user stories are written and hung up on a white board, cork board or wall. All different points of view are collected simultaneously, so every one understands the concerns of all those who are involved. Sometimes conflicting user stories emerge right away. The user story meeting usually lasts up to two hours.

Daily Stand-Up Meetings (or Scrums)

In Lean and Agile Project Management, project teams meet on a daily basis to discuss the tasks they will be working on. This allows team members to stay tuned to the project progress and to one another, to support each other with completion of tasks and to schedule the -offline- discussion of relevant issues.

Iteration Meetings

Finalizing the iteration, the team sits together to evaluate the previous iteration and to plan the next one. During this meeting the team looks back at the previous iteration – Have we completed all the user stories planned for the iteration? And we look forward to the next iteration, choosing the user stories to work on and scheduling the tasks for each story. The iteration meeting is particularly helpful to keep the team focus on completion of User stories and also of sharing the workload (heijunka!).

Iteration Meetings

Shortly before the release date, the project is released during a Release Meeting. This meeting is actually a longer version of the Iteration Meeting. During this meeting, other cross-iteration issues may be evaluated, as well as the quality of the product itself.

User Stories

User Stories are a peculiar way of describing a product or subproduct to be delivered by the project. The User Story is a phrase describing the client, the functionality and the value for that functionality for that client. The phrase can be a phrase like:

As a business traveller, I want to arrive on time, in order to have my meetings.

The value differentiates the user story from most other functionality tools: having defined the value, may help the project team to determine what exactly needs doing and also allows a search for alternatives. In the example above, an alternative solution for the business traveller, might be to have a conference call instead of a trip.

Planning Poker

Planning poker is a joyful way to estimate how much work it will be to deliver a task, user story or feature. Normally we are not very good at estimating the exact amount of work which we have never done before. Interestingly however, we are good at estimating relative amounts of work: We can quite accurately determine how much more work one particular job will require, compared to another. In Planning Poker we first choose one task, user story or feature which we understand well and which represents an average amount of work. We then establish that this user story has a certain number of story points &ndash say 5. Then we go through all the other stories, to determine their average amount of work &ndash compared to the standard. Planning poker is done with a deck of cards (½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞), as if we were playing poker. Every one gets to play a card from their perspective. Then, the lowest and highest estimator clarify their score. Perhaps some addtional knowledge is brought in by one expert or another. Then all participants play another round. Usually, the scores don't differ too much at this stage. The moderator decides on the amount of point the story will carry and writes it on the card. Sometimes a third round is needed. During this Planning Poker, all participants gain knowledge and insight on the nature of the story, the details and possible impediments. Details and tests resulting from this are added to the card. Note that the story points are abstract values, rather than absolute time units such as minutes, hours or days.


The client can set priorities after having played Planning Poker. Priorities are always based on the value of implementing them. Suppose our wish is a vehicle to drive to Rome. Now this could either be a Fiat 500 or a Ferrari, or anything in between. Therefor, we may have defined a number of User Stories, clarifying the details: number of seats, engine power, luggage volume, color, volume, safety options, radio and tv, navigation, seat quality. Without cost attached to it, we definitely will be inclined to want it all. With comparative cost attached to it, we may differentiate priorities. We normally use the distinction between MUST HAVES (basic needs or dissatisfiers), SHOULD HAVES (satisfiers), COULD HAVES (delighters) and even WON'T HAVES (things some users may want, but the client doesn't). It's good to strive for a normal distribution: 20 – 60 – 20. Priorities are set at the beginning of an Iteration.

Team Velocity

In Lean and Agile Project Management we're perfectly clear about the feasible Team velocitiy. This is the amount of story points the team is able to complete during an Iteration. It's important to know this Team Velocity beforehand, because it allows us to make valuable assumptions on amounts of work that can be completed.

Waypoint is project management software to support the execution of Lean and Agile projects, in software development, new product development, construction, Waypoint is software to support lean project leaders and teams. The software allows to budget, plan, report, standardize and improve project execution, along the principles of Lean Project Management and Agile Programming and Planning. Waypoint is offered by Heyunka, a provider of on-line tools for the implementation of lean management and agile development.Heyunka's tools are web-based and require standard compliant browser. Clients are charged only for actual usage -from one to as many users as you like and for as long as you need it. Tools are sold on-line. No IT needed.

Copyright © 2009-2012 Heyunka
Enjoy your lean journey

Please wait... loading