Agile is a versatile and vastly opinionated approach to driving teams towards company-lead goals. However, Agile also has the pitfall of forcing teams to have very little time to decide what tasks will get them to the intended goal, and what is nice to have. Therefore, in this article, we will outline NearPlan, an attempt to take this problem, and come up with a solution that totally will not work.
There are plenty of planning methods for Agile, but in the same spirit of creating esoteric programming languages, this article will attempt to design a simple, straightforward and weird methodology of taking the KonMari method and applying it to create Near-Term, Value Driven Planning.
Specifications – NearPlan:
- It should span two (2) sprint periods ahead. For most of you, that would be one (1) month into the future.
- It should be based off of a long-term roadmap (around a year). If your team does not have one, that should be your first task.
- Goals that will take more than 2 sprint periods need to be broken down into smaller goals.
- Keep it simple! Try to avoid unnecessary jargon and technology-locking. If your goal is towards a particular technology though, it may be useful to use umbrella terminology.
- It should involve negotiation with management and other team’s priorities, but should come down to the key goal- Value. Remember, Nice-to-haves are not Value.
- It should not be based on Story Points. Firstly, the point of this exercise is not to discuss technicalities within how long implementing xyz feature will take. Secondly, your team should not try to sneak in Nice To Have’s because the work seems minimal.
- If your team finds getting what needs to be done versus what would be nice to have to get to a goal difficult, then you may find the Critical Path planning method useful.
- Below is an example of what should be created every two sprint periods.
- There are three Value Types. Functional (you need this technical/people/design/etc. component to achieve the goal), Monetary (you need this component to get money from clients from this goal), and Time (reducing fires, overhead, increase automation).
- Value Levels are up to your team, but a recommend scheme is “Low, Moderate, High, Critical”. This is “Value Level during this timeframe”.
- Have Jira Epics or something similar to base “Task” on, or your team can create them as a result of this task.
- Aim to put the tasks in chronological order.
- The last column is a Y/N completion column, which should be updated in tandem with task completions.
Example – NearPlan
Goal: Migrate iShoppy to Kubernetes (Due: 20xx/0x/01)
| Task | Benefit | Value Type | Value Level | ? |
|---|---|---|---|---|
| Notify Support / Management of Migration | Communication | Time | Critical | Y |
| Build Docker image for iShoppy | Technical | Functional | Critical | Y |
| Set up logging in Kubernetes | Compliance | Monetary | Critical | Y |
| Deploy iShoppy to Staging | Technical | Functional | Critical | Y |
| Test iShoppy with QA Engineers | Risk Reduction | Time | High | Y |
| Deploy Health Check for iShoppy | Alerting for downtime | Monetary | High | N |
| Promote iShoppy to Production | Goal Completion | Monetary | High | N |
Conclusion
In conclusion, hopefully the NearPlan exercise can help your team:
- Firstly, break free of “small task” confusion.
- Secondly, have an overarching goal to reach by the end of the period that all team members are contributing to.
- Thirdly, manage priorities and hit VALUE driven targets.
- Lastly, improve trust within between your teams.
If you liked this article, you might like others similar to it, such as Why Kubernetes?, or another opinion piece like Applying Tokyo’s train network practices to Systems Engineering.