
WikiFree learning path 12 · Beginner
The flow room
Finish work before starting more.
Design a small pull-based workflow, apply work-in-progress limits and use cycle-time evidence to improve one bottleneck.

Video duration uses the selected lessons only. Reading and practice times are planning estimates; repeat difficult work as needed.
A clear starting point
Who this is for
Basic spreadsheet use or paper cards; Trello is an optional interface.
Your practical result
Design a small pull-based workflow, apply work-in-progress limits and use cycle-time evidence to improve one bottleneck.
This route covers a small service workflow, not a full Kanban certification or enterprise portfolio system.
Access and cost
The videos are free. Complete all assessed work on paper or in a spreadsheet; a Trello account and paid automation features are not required.
The project pack contains an original workbook, case inputs, an evidence log and reference notes. Some technical paths include starter code and a runnable reference. Read the pack README before starting.
Three-minute readiness check
Answer first, then open each explanation. A missed answer identifies what to revisit; it does not stop you from starting.
Does moving a card prove the work is done?
No. The exit policy and evidence determine completion.
What happens when review is full?
Help clear review or address the blockage before pulling more production work.
Is the average a delivery promise?
No. It summarizes this sample and hides variation.
The case you will work on
Juniper Studio receives design requests. Today three items are in production and one waits for review. The team wants shorter and more predictable completion, not the fullest board. Treat the times below as a small synthetic sample.
| Request | Work time, days | Queue time, days |
|---|---|---|
| Poster | 2 | 4 |
| Flyer | 1 | 2 |
| Banner | 3 | 5 |
| Icon set | 2 | 3 |
| Event card | 1 | 4 |
These are supplied synthetic inputs, not observations from a real organization. Label assumptions and any additional data you create.
Keep an evidence trail
Save each stage output in the project folder. In evidence_log.csv, record the decision, the artifact or test that supports it, what failed, and the revision you made.
Your route from learning to evidence
- Stage 1Map the actual workflowA workflow and five transition policies45 minutes of original practice
- Stage 2Make pull policies explicitA pull policy and urgent-work rule60 minutes of original practice
- Stage 3Measure elapsed timeA cycle-time summary with boundaries60 minutes of original practice
- Stage 4Investigate a blockageA blockage response and handoff checklist45 minutes of original practice
- Stage 5Run one improvement experimentA two-week experiment charter60 minutes of original practice
- Final projectMake the evidence reviewableConnect the five stage outputs and test a change.150 minutes estimated
Progress stays in this browser. Tick a stage only after its evidence check passes. This is a personal checklist, not a certificate.
Why these source courses
The path uses selected material from courses already published on WikiFree. The original exercises below connect that material to one practical outcome. Follow only the listed assignments; completing the full source courses is optional.
Learn Skills Daily
Trello Project Management: Free Course
The beginner tutorial provides a concrete board interface; the later selection helps translate the written policies into a practical board.
Access: Free Video
Certificate: Free video viewing; certificate not included
Learn it, apply it, check it
Work in order. Every stage produces something the next stage uses. Revisit the repair instruction when a check fails.
Map the actual workflow
Basic spreadsheet use or paper cards; Trello is an optional interface.
The idea to use
Map the states work really passes through, including waiting. A board with only to do and done may hide the review queue. Write a clear start and finish boundary before measuring elapsed time. Keep an explicit blocked marker without pretending a blocked item has left work in progress. A digital board is optional; policies make the system useful.
Watch the selected lessons
Selected video time: 27m. Open this course on WikiFree.
Your 45-minute lab
Draw Requested, Ready, Doing, Review and Done. For each transition, specify the evidence or decision that permits it.
Save: A workflow and five transition policies.
Evidence check
A reviewer can place a new request in one unambiguous state.
If it fails: If cards frequently jump states, check whether the board reflects the real process.
Make pull policies explicit
Bring your previous output: A workflow and five transition policies
The idea to use
A work-in-progress limit constrains started but unfinished work. It is a signal to collaborate and finish, not a quota to make people look busy. Different states can have different limits. Decide how urgent work is recognized and who may change its priority; otherwise every requester can bypass the policy by writing urgent.
Original practice stage. No additional video or reading assignment is required.
Your 60-minute lab
Set Doing to three and Review to one. Introduce a new urgent banner while both are full, then write the response without silently breaking the limits.
Save: A pull policy and urgent-work rule.
Evidence check
The response identifies a finishing or explicit reprioritization action, not an invisible extra slot.
If it fails: If limits are routinely ignored, reduce intake or address the bottleneck before changing the number.
Measure elapsed time
Bring your previous output: A pull policy and urgent-work rule
The idea to use
Cycle time is meaningful only with defined boundaries. In this case, elapsed time from Doing to Done equals work time plus queue time. Keep both components because improving productive effort will not necessarily fix a waiting problem. Use the median alongside the range. Five observations can start a discussion but cannot establish a reliable long-term service-level forecast.
Original practice stage. No additional video or reading assignment is required.
Your 60-minute lab
Calculate each elapsed time, the median, the minimum and maximum. Compare total work time with total queue time and identify the larger component.
Save: A cycle-time summary with boundaries.
Evidence check
Results are 6, 3, 8, 5 and 5 days; median 5 and range 3–8.
If it fails: If numbers differ, check whether waiting was excluded or the median was calculated before sorting.
Investigate a blockage
Bring your previous output: A cycle-time summary with boundaries
The idea to use
A blocked card needs a reason, an owner for the next action and a review time. Those fields help the team act; they should not become a surveillance record. In Juniper, review waits because only one reviewer knows the brand rules. Consider making those rules visible and pairing on reviews. Automating card movement will not remove the knowledge constraint.
Watch the selected lessons
Selected video time: 39m. Open this course on WikiFree.
Your 45-minute lab
Write a blocked-card policy and a reviewer handoff checklist. Compare a second-reviewer experiment with an automation-only proposal.
Save: A blockage response and handoff checklist.
Evidence check
The intervention addresses the cause of waiting and preserves an accountable next action.
If it fails: If the proposed fix is a tool purchase, first explain which observed delay it removes.
Run one improvement experiment
Bring your previous output: A blockage response and handoff checklist
The idea to use
Change one policy and observe its effect over a defined window. A shorter cycle time accompanied by more rework may not be an improvement. Choose a primary flow measure and a balancing measure. Keep the original data so that later comparisons remain interpretable. Do not claim causality from a tiny before-and-after sample.
Original practice stage. No additional video or reading assignment is required.
Your 60-minute lab
Plan a two-week paired-review experiment. Record cycle time, rework count and a decision threshold for retaining or changing the policy.
Save: A two-week experiment charter.
Evidence check
The plan names a comparison method and a balancing measure, with no guaranteed result.
If it fails: If several policies change together, simplify the experiment or state that attribution will be uncertain.
A worked reference to compare
The five items total 27 elapsed days: 9 work days and 18 queue days. Waiting therefore represents two-thirds of observed elapsed time. This makes review delay a reasonable investigation target, not proof that every future request should finish in five days.
Compare your reasoning as well as the result. If your answer differs, state the assumption or input that explains the difference. Reference notes are for checking after an attempt; copying them is not evidence of independent work.
Your final project
Your brief
Build the Juniper workflow playbook with a board, pull and blocked-item policies, a worked flow summary and a measured improvement experiment.
Time box: 2h 30m estimated. Extend it if a gate needs repair.
Hand in these artifacts
- A workflow and five transition policies
- A pull policy and urgent-work rule
- A cycle-time summary with boundaries
- A blockage response and handoff checklist
- A two-week experiment charter
- A short README: outcome, how to inspect or run the work, assumptions and limitations.
- A before-and-after change test and the completed evidence log.
Run a final review
- Use the supplied reference to reconcile the baseline result.
- Choose one relevant input or constraint to change. Write your expected effect before testing it.
- Run the calculation, walkthrough or test again and save the actual result.
- Ask a peer to inspect the evidence, or perform a separate self-review. Label which review you used.
- Score the work using the rubric and repair every critical failure.
Review rubric · 100 points
| Criterion | Points | Evidence to inspect |
|---|---|---|
| Practical outcome and case reasoning | 25 | Design a small pull-based workflow, apply work-in-progress limits and use cycle-time evidence to improve one bottleneck. |
| Five stage checks | 30 | Award 6 points for each stage only when its stated gate is demonstrably met. |
| Traceable evidence | 20 | Artifacts, inputs and calculations or tests are reproducible; synthetic and simulated evidence is labelled. |
| Revision after a changed condition | 15 | Change one input or constraint, predict the effect, test it and record the result. |
| Handoff quality | 10 | A reviewer can find the files, follow the instructions and understand the remaining limitations. |
Completion target: at least 80/100, all five stage gates passed, and every critical issue below corrected. This is a learning benchmark, not an accredited qualification.
Critical issue: Do not remove blocked work from WIP counts or turn a five-item median into a guaranteed deadline.
Before you go further
What will I be able to produce?
Design a small pull-based workflow, apply work-in-progress limits and use cycle-time evidence to improve one bottleneck.
Is the whole path free?
The videos are free. Complete all assessed work on paper or in a spreadsheet; a Trello account and paid automation features are not required.
Do I need to finish every source course?
No. Follow the selected assignments at each stage. Source courses provide context, while the original case, labs and final review build the practical result. Extra study is optional.
What counts as completion?
Complete all five stage checks, earn at least 80/100 on the final rubric and correct every critical issue. This route covers a small service workflow, not a full Kanban certification or enterprise portfolio system.
Questions & discussion
Share a useful question or correction. Comments appear after moderation. Please avoid personal or sensitive information.