Agile Pulse Model – Project pulse

The projects have daily pulse meetings at which the participants in the active project teams decide which activities need to be dealt with in order to make progress. The project teams should be self-organizing and self-governing. Moving post-it notes in the activity window and putting up yellow, red and green magnets in the synchronization plan is done by the members of the team (not the project manager).

The project manager should however record decisions in the decision log. The project manager should also ensure that a completed activity is marked as completed in the activity plan.

A project follows its unique value flow through the compiled synchronization plan. However, the plan does not stipulate what work to be done, only which subresults should be achieved and how
these relate to each other.

Step 1. Daily pulse meetings

The project pulse meeting follows a four-step basic form. Decisions that are made during project pulse are documented in the decision log by the project manager.

1. Show progress. Move post-it notes with completed activities from “In progress” to “Done”. The participants also shortly explain what they have done so that the whole project team understands what has been completed and if it does influence how other activities must be resolved.

2. Act on problems and risks. Identify any obstacles and other difficulties that are unanticipated. In order to avoid waste, these obstacles and difficulties must be addressed as soon as possible. They will otherwise obstruct the progress, forcing the project into a situation where things must be redone and causing delays. A problem that arises and high risks generate one or more activities to be put up under “To do” in the activity window.

3. Prioritize new activities. Adding new activities from the activity plans or period log to activity window’s “To Do”.

4. Decide what to do next. The team’s members select which activities they will do by tomorrow. It is important to allow everyone to clearly explain what they intend to do. Some team participants may have ongoing activities with post-it notes already placed under “In Progress”. Others check out a new activity from “To Do” and put it under “In Progress”.

Step 2. Daily retrospective

Discuss work and cooperation in the project, attend to any obstacles and jointly agree on how to resolve them. This will provide conditions for the team to self-organize and create more value.

Step 3. Weekly before program pulse

The points below are discussed in a project pulse meeting before
weekly scheduled program pulse meeting.

1. Needs for help with decisions are identified. The project manager will bring requests for decisions to the program pulse.

2. Resource requirements is updated.  The project manager will bring requests for resources to the program pulse.


Project Pulse Board - Agile Pulse Model
Project Pulse Board


Project Cyber Pulse Board – Agile Pulse Model

To visualize the chain of events for activities in progress, a activity window is used that is divided into “To Do”, “In Progress” and “Done”. Activities can be initiated via actions related to problems and risks, activity plans for sub results in progress or the synchronization plan/period plan for a new subresult.

A problem that requires activities have priority over the planned activities. In order to differentiate between planned activities and activities related to problems and risks, use different-coloured post-it notes.

When it is time to soon start working with an activity, it is posted as a post-it note in the “To Do” area. When someone in the project team starts working on the activity, the post-it note is moved to “In Progress”. When the activity is finished, the post-it note is moved to “Done”. The “Done” area needs to be emptied regularly so that it does not overflow. This can be done weekly after program pulse.

Go from here

Perform weekly Program pulse.

Plan next subresult with Activity plan.

Back to Agile Pulse Model.

Creative Commons License
Agile Pulse Model by Parmatur HB is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Making Organizations Agile