Focus On Sharing Plans
Focus On Sharing Plans
The team shares its plans openly as a matter of routine. Sharing occurs in the context of open team events, but also in the context of making its plans available to any stakeholder. Plans include immediate delivery work plans, the backlog of future work and the Product Roadmap. The use of information radiators is a natural part of the teams culture and working practice.
In A Nutshell
The team is open with all its stakeholders about its plans for work - the backlog items that are being worked on and the priorities for future items. Plans made available to the team’s stakeholders may include:
current work plans (for example, the Sprint Backlog in Scrum or the ready for work queue in Kanban)
short term plans (for example, the prioritised product backlog)
medium term plans (for example, the product roadmap)
The team may choose to distinguish between classes of work, showing items that relate to the development of the product differently from those that apply to improving the team’s behaviours or ways of working.
In a physical work environment, plans can be shared on whiteboards. In a virtual work environment plans are shared using the standard tools adopted by the team. Most importantly the team does not do any additional work to provide visibility of its plans, so there is no marginal cost associated with the team’s transparency.
Team events that engage with planning work are normally kept open to stakeholders. The team takes steps to encourage stakeholders to attend. The role of stakeholders will vary depending on the type of planning being undertaken. When planning immediate work, stakeholders may be asked to simply observe. For longer term planning involving high-level needs and priorities, stakeholders may play a more active role.
We have observed that, in many organisations, there is a demand for special presentation of plans by senior stakeholders. We specifically resist such demands because of the cost of providing the special presentation. For example, there should be no question of providing a “roadmap on a page” for consumption by the senior stakeholder group.
Nor should the demands of senior stakeholders be permitted to constrain the choices of the team around how plans are managed. We have observed that demands for standardisation of presentation are often used to impose such constraints.
However, the teams within the organisation should work to collaborate and converge on a useful standard for presenting plans. Such standards are permissive in nature so that, when teams have different needs for planning, these can be taken into account. The standards may take the needs of senior stakeholders into account, but focus on the needs of the primary stakeholders - the customers and the teams.
Implementing Practices
Teams plan work to fill their short-term planning horizon. With a clear understanding of current priorities and the capacity of the team, work items are chosen to satisfy the forthcoming delivery goals. The team elaborates the plan as necessary to ensure that there is a shared understanding of the work that is required.
The Product Backlog is the vehicle by which needs are turned into requirements and requirements are turned into operational features in our product. It is a prioritised list of the work that the team currently intends to deliver in the next period of time. The less imminent a feature is, the less well it will be defined.
The Product Roadmap provides a simple view of how the product will grow towards its vision. As a forward looking view, the roadmap does not set fixed priorities or deadlines. Rather it is a fluid view that evolves as our understanding of customers’ needs evolves. Roadmaps are influenced by concerns in addition to the customers’ needs. These may include our capability and capacity to deliver change and the business, financial and legal context in which our product operates.
Sprint Planning is a Scrum event that is held before the start of the sprint to establish the scope and priorities of the coming sprint. Its purpose is for the whole team to establish an agreed sprint goal based on the Product Owner’s view of the value that can be created for the customer. To establish a scope of backlog items that can be got to done. For each backlog item the team decides how done will be achieved.