Organizations using PMPeople run multiple projects organized into business units, portfolios, and programs. Depending on the development approach for deliverables, some projects are predictive, some of them are adaptive, and others are hybrid.

Our recommendation to manage the agile part of a project is to keep project management in PMPeople, decomposing the project into work packages, meaning agile releases. Work package #0 (meaning the project itself) can include PMPeople tasks for the main features (a.k.a. epics), and releases can include PMPeople tasks as operational features to be demonstrated to stakeholders (a.k.a. user stories). To enhance collaboration with the development team, we recommend using our built-in integration with Asana: Asana projects can be linked to PMPeople work packages, so that senior managers do not have to enter Asana.

Let’s see how this can be done in practice, in an agile cycle starting with the project planning and ending with the first retrospective. For the sake of simplicity, let’s have the project manager playing the roles of agile coach and product owner. The name for the agile project is PR1:

  1. Project Manager facilitates release planning: Team Members review the current version of the product backlog to decide which stories (or epics) are the most valuable for the new release. During the discussion, new stories are added, clarifications are annotated, some items are parked, etc., resulting a list of prioritized items in the Asana project for the release named as PR1_REL1. All items are shared with the list for the product backlog PR1_PBL. Relevant items to be shared with senior managers can be shared in another list named PR1_EPICS. Items which are parked or labelled for further analysis are moved to list PR1_PARKING.
  2. Project Manager plans the project: Project Manager uses PMPeople to share the relevant information on business case, project charter, stakeholder register, deliverables, requirements, risks, schedule, milestones, cost, etc. Project status is set to execution.
  3. Team Members can check their assignments to the package named REL1 in PMPeople. They can collaborate to elaborate a team charter. They can register happiness index anonymously, submit comments aimed to the Project Manager, etc.
  4. Project Manager connects work package #0 and REL1 to Asana projects PR1_EPICS and PR1_REL1, respectively.
  5. Project Manager explains the functionality expected for the first sprint. Team Members decompose features into technical tasks. They can use a list for the first sprint backlog for the first release of the project PR1, as Asana project PR1_SPR1.1. User stories are also included in this list and technical tasks are set as Asana subtasks and shared as cards in another Asana project for the KANBAN board, “to-do” section.
  6. Team Members use the KANBAN board during the daily stand-ups. When a Team Member choose a task to do, everyone can check the assignee name and due date. One-piece-flow good practice is enforced if no one has more than one card in the “in-progress” section of the KANBAN board. If some tasks are impeded, this can be properly annotated in the description section for the task and labelled visually in title with an emoji 😡 on the task title. Good practice is impediments are solved before the next daily meeting, following the rule: “Not two dailies talking about the same impediment.”
  7. If Team Members annotate ideal hours (planned vs. pending) in Asana tasks, then Project Manager can easily update the sprint burndown chart. If user stories are estimated with story points, Project Manager can update release burndown chart as well.
  8. Team Members can submit hours and expenses anytime using mobile or web application. Project Manager can approve/reject hours and expenses at the end of each week. If cost control is needed, online reporting avoids paperwork and processes waste.
  9. When a Team Member completes a task, he or she marks it as complete in KANBAN board (or in the list PR1_SPR1.1) and moves it to “done” section in KANBAN. When all tasks for a user story are done, the Project Manager can mark it as complete in PR1_REL1. Epics and stories data can be automatically synced from Asana to PMPeople.
  10. Only the completed stories are demonstrated to Stakeholders by Team Members during the sprint demo. If a story is not acceptable, it is marked as incomplete. Incomplete stories will be easily planned later.
  11. In PMPeople, agile Project Managers usually plan review dates as the end of sprints. Project Manager can register the right information on status report for release 1 and for the whole project. Stakeholders can check project status in mobile or web application.
  12. Finally, the Project Manager can facilitate the retrospective meeting with the team if Team Members have annotated their happiness index information in PMPeople.

PMPeople is the tool for the project economy. It is aimed to unify professional project management by these differential points:

  • Designed by and for professional project managers, following professional project management standards.
  • Online productivity –less meetings, less documents, less workflows– through distributed collaboration among 12 specialized roles: Organization Owner, 6 roles on demand management and 5 roles on supply management.
  • Freemium product –unlimited time, unlimited users, only managers have to pay– usable via web and mobile application.

Start using PMPeople for free, for unlimited time and for any number of users. In premium organizations, only managers have to pay. Several roles –stakeholders, team members, sponsors and resource managers– are always free. You can increase or decrease your premium seats according to the organization actual needs. Premium organizations have access to our interactive support through Slack. Our servers are located in EU. This software can also be hosted on customer premises.

Read this article in Spanish.