After the last post, we need to talk about some things before we can really get a handle on what Microsoft Planner can do.
There’s a lot to this and it’s a long post, so it’s a bit of a story.
Picture it. Sicily. 1949.
Just kidding.
I’m going to lay this out like video game levels instead.
Level 0
Pretend you have a project. It’s pretty darn important.
And imagine, if you will, a whiteboard. Grab your dry erase marker (not the Sharpie) and divide it into 3 columns with a header row. Label them left-to-right To Do, Doing and Done. You can have more columns. It’s about tracking status.
Good? Great. Now grab your sticky notes. On each one, write the task or activity to complete and put them all in the To Do column.
Keep in mind you should write each task as an epic user story. Phrasing tasks as stories just plain works better. In the words of the stakeholder is even better.
As a PERSON, I can ACTION my THING.
LPT: Remember to peel the stickies off the stack sideways so they don’t curl.
Level 1
Take the three immediately doable stories and put ‘em in the doing column.
Do the things. Move the completed tasks to Done.
You flow value left to right.
Congratulations, you have completed Level 1.
Level 2
As you complete a story in Doing, move the next story from To Do to Doing. Keep only three items in the Doing column at all times.
This Work-In-Progress limit keeps you focused on doing the work.
Can it be more than three? Sure. Pick a time limit. How many stories can you do in one day or one week? That’s you’re WIP queue length.
Tune your WIP accordingly. Everyone is different and each project is different. Your WIP for one project may be different than for another. Same with people.
The important thing is that your WIP is relative.
Level 3
“But not every story is the same, Doug!” you say.
Nope. Some stories are harder than others. Some are more complex. Some take more time. How do you deal with effort estimates in a kanban board.
Here’s a truth. One you all know inherently. Project managers hate this fact too.
People suck at estimating time. There I’ve said it.
For the most part, we rely on historical data to come up with effort estimates. But it’s error prone because people and situations are different.
All is not lost, tho.
Humans are totally boss at comparing things. It’s how we get along in this big bad world. It’s how we learn.
In the context of user stories, it means we can say that one story is harder than another. We can even say that one story is twice as hard as another.
So, take a gander at all your sticky notes. Score each one for how hard it is.
1, for easy-peasy-lemon-squeezy
2, for minimal effort
3, for twice as hard as 2
5, for hard things
8, for super hard things
If you got a ‘8’, you should consider breaking that down. It’s too hard.
Why no ‘4’ or ‘6’ or ‘7’? I dunno. I read somewhere that people tend to underestimate hard pieces of work. And I really like the Fibonacci Sequence. It resonates with me at a spiritual level. It’s my jam.
It’s arbitrary. Keep your scoring rubric simple and consistent.
Anyway. These things are called Story Points.
Your WIP queue length is now the number of Story Points you can achieve in the designated time frame, typically a day.
If you feel compelled to map story points to hours, then a good rule is:
1 point = 8 hours, 2 points = 16 hours, 3 points = 24 hours, 5 points = 40 hours
But, if points map to hours for you, you’re using tasks not stories. Revisit.
Level 4
If you’re a team, you must agree on the Story Point value of each user story.
Grab your dry erase marker again and resist sniffing the cap. The headache isn’t worth the fruity smell.
Draw rows in for the Doing column, one for each team member. Leave a tiny row at the bottom. In the corner of each box, write the team member’s WIP queue length and in the bottom box, write the total WIP.
Each member is responsible for taking the next most appropriate sticky from the To Do column and put it in their Doing box, keeping mindful of their own WIP limit.
Value flows left to right.
Level 5
You measure and report progress using a Burndown Chart– with Time on the X access and remaining Story Points on the Y axis.
If you business-types only like graphs going up and to the right, sorry #notsorry.
If the project is slated for 11 days and you have 30 story points to complete, then you draw a straight line from 30 on day 1 of the chart to 0 on day 11.
This line is your standard. Every day, you’ll plot the remaining story points on the chart. If you’re below the line, you’re ahead of schedule. If you’re above the line, you’re behind.
Real-time and very visual. Velocity is the number of points completed per day.
Here’s a bonus: Because folks are choosing the next most valuable story to complete, as the project gets close to the finish line, only low-value stories remain. It often comes to pass that those last few stories are unneeded or just gold plating.
It’s day 9. You just might be done. Check. This happens a lot in Kanban-managed projects.
Level 6
We’ve really only talked about a single sprint.
A big tenet in Agile is iterative results. Versioning, if that makes sense. While a traditionally managed project would break larger work into phases and milestones, Agile uses sprints and version releases.
Fix time and flex scope.
Say you have a three month project. You can decide that that’s three equal sprints of four weeks.
At the end of each sprint, you release/publish/share whatever targeted outcome you’ve achieved with the stakeholders.
There are many ways to do this on a kanban board, but here’s one way for a simple project.
Take the marker again. Did you leave the cap off? Too bad. Grab another.
On a clean whiteboard, draw four columns instead of three. Label them: Backlog, Current Sprint, Doing and Done. Under Current Sprint, write or put a bold sticky that describes the ‘epic story for the sprint’.
Move the stickies from the Backlog to Current Sprint that meets the Sprint Theme. Work the system.
Level 7
At the end of each sprint and before you start the next one, stop and celebrate your win. Then have you’re Kaizen moment. Adjust your WIPs and layout your next sprint.
What’s a Kaizen?
It’s a stop point where you make sure you’re engaged in Continuous Improvement. It can be as simple as each team member raising one good way to improve for the next sprint. Or you could take it Next Level. Up to you.
Both Kanban boards and Kaizen philosophy came from the Japanese industrial revolution, specifically from Toyota and the work of William Deming. It’s a worthy trip to Wikipedia if you’re interested.
Hopefully, this has been a good primer on Kanban and Agile.
There’s a whole lot more to talk about; but that’s the subject of books, not blog posts.
Next week, we’ll map these concepts to Microsoft Planner and where Microsoft is headed with its project management tool-set.
