Two days in, I already had cool graphs.
Reality Check had plenty of technical work and no consistent way to see how it was moving. A few of us spent several weeks putting together a simple process for the team.
We split the company into two working groups. Larger needs became user stories. The teams broke those stories into tasks that should take no more than four hours, gave each task a clear definition of done, and committed to a two-week sprint.
The daily part was short. Update the remaining time, say what moved, say what was blocked, and get back to work. The project system could turn that information into a burn-down chart.
I liked the chart immediately.
It was not because the graph made the company more sophisticated. It showed where our guesses were wrong. It exposed work that looked small but was not. It made it easier to ask whether a team needed help before the end of the sprint arrived.
The interface was not universally loved. That was fine. I walked everybody through it myself, and one person started showing me useful things inside it within fifteen minutes. The team did not need to become project-management software experts. The system needed to stay out of their way while giving us a shared view.
We were also short on backlog. A two-week sprint only works if there is enough real work behind it to choose from. I wanted roughly three months of stories ready so priority conversations could be about what mattered most, not whatever somebody remembered that morning.
This was my first month at Reality Check. I was still learning the weak spots while changing how the team worked.
The process would need adjustment. The graphs were already telling us something.