Agile Reporting – Beginner To Rock Star

Each of your reports communicates some color of truth. Maybe your Gantt chart is saying that you'll miss a milestone. Maybe your budget has a small variance. Each of these reports is like a little point of color, they tell you one small thing, they're not designed to communicate the big picture. For that, you have to step back and look at all the reports together. Only then will you see the whole project. Often, there are many reports that say the same thing. Some will be out-of-date, some will be confusing or incomplete. The closer you look, the less you see about the health of the project. Agile takes a different approach. Instead of numbers and variances, Agile communicates large truths with simple images. This is commonly called a team's transparency. Are they going too fast or slow? W

When I was a traditional project manager,I would create two sets of reports.One for the team, and one for the stakeholders.I would work on each set independently.I updated the internal reports daily.Then it would translate the same information into an executive overview.I spent a good deal of my time communicating

In traditional project management the team relies on completed requirements before the work begins.In Agile, the backlog replaces these requirements.The product backlog is a ranked list of user stories.These stories drive the project.In Agile, the backlog doesn't try to capture all the work.Instead, it's an ever changing document.The product owner has the sole authority to add or change the work to the backlog.Then the list gets reprioritized based on the changes.The highest value stories are reordered and pushed to the top.

The product backlog is always changing.The product owner should work on the list several hours a week.They'll be clarifying the stories, and adding new ones as they find more work.In scrum's early years, this was called backlog grooming.The scrum community later changed this term,they settled on the term backlog refinement.Whatever you call it, the activity is pretty much the same.In your backlog you typically have a list of user stories.This is often called your product backlog items,or PBIs.

The task board is one oft he most recognized Agile artifacts.It's like an Agile signpost.Almost like a billboard that reads,"Quiet please. Agile team working."Often managers will use the task board as a signal of progress.They'll point and say,"This is our Agile team."Something about the board attracts the ohs and ahs from people who visit the team.It shows that the team is doing something different.It takes Agile from being theory something practical.  

The task board is the developer's mostly widely used information radiator.A quick glance at the board should tell you everything that you need.It should be simple and clear.Still, there's some information that's not easily visible to everyone.The task board doesn't just radiate the work,it also radiates the team's passion and commitment.Is the board updated and filled with tasks?

The task board is a team report.It's designed to help the developers coordinate. if you're the scrum master of the team,then you need to help ensure that only the developers update the board.This starts with the sprint planning meeting.During sprint planning,the team will agree on the stories for the sprint.They'll put their stories in the far left, stories column. 

In Agile, it's very important to size the work in each sprint.It's a key part of how the team plans out the project.That's another reason that the task board is an essential information radiator.For scrum teams,it's a report of the developer's workload.The board shows all the work for that sprint.

When I was in college I took a few courses in Philosophy.In one of the lectures, the professor told us the story of Zeno's paradox.The story was about a race between Achilles who was a famous Greek warrior, and a tortoise.The tortoise told Achilles that it could beat him in a foot race.

At some point, a stake holder will ask, "How's it going with your project?"When that happens, you don't want to give him a rundown of the team's philosophy.Instead, they'll want to hear something like,"We're on track," or, "Things are looking good."Then you can point to a high-level chart.For most agile teams, this high-level chart is the burndown. Like all reports, the burn down is only as good as the information that goes into making it. 

The burndown charts are a powerful information radiator.They shed light on many of the obstacles the team encounters.

The release burndown is a big picture chart.It's designed to give you an overall view of your project.If you use this burndown, be sure to use it for the whole project.Don't erase the board if it starts to show challenges.You need to keep the chart updated and transparent.The release burndown is similar to the sprint burndown. 

A new project manager could plug in the templates,and immediately get to work.Everybody knew what to use,and everybody knew what to expect.But this library ended up being an obstacle for the team.For traditional project managers, these resources are tough to abandon.What often happens is an organization will try to retrofit the documents to make them more agile.It's important to avoid retrofitting your documents to make them more agile.Instead, create new documents.If you can, use existing agile charts and reports.Making this decision itself can be a process.But sometimes compromises are necessary.

In Agile, there's a lot of emphasis on working in a shared workspace. That said, it's often unrealistic to have every team member in the same room.Many large organizations outsource development to companies that specialize in niche technology.

Something where as you're going along,you realize that there might be changes.Like if you're working on a software project.A lot of modern software projects depend on open source frameworks,open source tools, and those tools are being developed simultaneously alongside your project.

Yeah the question is how can you delivers project without requirements?Well, what Agile does is it focuses on predictability and not planning,and there's a key difference between the two.Planning, you're trying to figure out everything that's going to happen, it's deterministic,like if you're going to build a road,you'd probably want to do some planning,you know, you want to know where the road is going to go,especially if you need to make bridges and other things.

The question is,isn't Agile just an excuse for scope creep?Well, in a typical Agile project, there is no scope.So, I guess big picture answer to that question is,yes, it is scope creep, because there's no scope.But Agile doesn't focus on what you're going to deliver at the end,like what you'd have with a typical scope.