Some guidelines on status reporting which have worked well on projects I have worked on:
Adopt an "active" approach: passive reporting is not productive because when it comes to project status, what matters is to tell people what's important for them to know at that particular point of time in the project. Passive reporting carries the risks of people ...
Essentially, I want to be able to demonstrate the effectiveness of the
recent time that we've spent dedicated to bug fixes.
It's obviously good news that you've fixed all these bugs, but as a manager/senior stakeholder my first question would be why there were so many bugs to fix in the first place. Because of this I'd suggest that in addition to ...
In the same way that a UX designer is responsible for creating an excellent user experience, a Scrum Master is responsible for creating an excellent project experience for those people who use the team to turn their ideas into reality.
By looking at the "team" from the external perspective, we can easily narrow down those bits of Scrum that are relevant ...
Not only acceptable but expected in many environments. If you do project management for the US government, OMB & ECPIC absolutely require you to report progress in %.
There is a deeper problem however; not how you report the %, but how you measure progress. Glenn Alleman has many blog posts and at least one book that touches on the topic. (My only ...
The Team Should Update the Sprint Backlog Daily
Whether the Team is using a Kanban board or an Excel spreadsheet, there ought to be a canonical source for the Team's Sprint Backlog items. Members of the Scrum Team ought to update the Sprint Backlog at least daily, even if the only change is checking for tasks that meet the "definition of done" and marking ...
The message should be as factual and emotion-free as possible:
Indicate the issue in a precise, straight forward, and simple way;
Describe how the customer will be impacted;
Indicate the the likelihood and degree of impact;
Detail the cause(s) of the issue;
If the issue was predicted in your risk program, outline what you did to try to mitigate it;
There are some other good answers here, but "percent complete" is not only tricky to calculate reliably, but it's often implicitly tied to scheduling. That makes it difficult to talk about it without talking about schedule variance, too.
Percentages of Tasks Completed
We've all seen software installers that zoom from 0% to 83% complete in a matter ...
Start with the "why". What information exactly is it that Senior Management is looking for. What are they using that information for?
It could be as simple as wanting to see progress, or open to closed incidents. Until you know exactly what the information is for, you'll be doing a lot of wheel spinning. For example, I started at one company and they had a ...
Actually I can think of two approaches here.
Individual reporting for each project combined in a single place.
Cumulative Flow Diagram (CFD)
may come handy in this case. Putting them all on a single board/monitor can tell you much about projects status, although information will likely be hard to consume.
A better idea for me is ...
Scrum is for Teams
While you could use Scrum in a one-person shop, Scrum is really a framework that's designed for teams rather than individuals. The underlying inspect-and-adapt philosophy is also available to a one-man shop using Kanban or Extreme Programming (XP); XP in particular is often a great fit when you want agile practices rather than a project ...
Have you considered exporting the relevant data to Excel? If you display the Task Sheet (use the View ribbon) you can certainly save that view as PDF as well. Saving as PDF just prints the current view to a PDF printer.
I would filter and show only the tasks of interest - instead of saving the entire list.
There are quite a bit of different tools you mentioned up there. So I will just hit on a couple of tools that I use:
1) Card Wall. Yes, I know it is low tech, but the visibility and collaboration this brings to team is great. Otherwise, you are expecting someone to log into a piece of software every day to perform some actions.
2) Software that I ...
The thing is that the Scrum meeting shouldn't be technical. There is a meeting called Community of Practice (CoP) and that meeting is for the Scrum Teams to talk about technical problems. So if you can keep the technical discussions out of the Scrum or Scrum-of-Scrums, your managers will be just fine. It is up to the Scrum Master and how he mentors others ...
At various points, your project is potentially 1.5 weeks late or 4 days early. Your methodology values calculated variances, but (as far as I know) doesn't mandate continuous re-planning. It would therefore be more efficient to value communication over re-scheduling.
Communication: The Underlying Question?
In your question, you state that at some ...
First of all: Why RAG instead of numbers with a legend or text? Because it's faster to grasp. From our cultural background we know that red is a warning color, yellow is something to be aware of, and green is more like ok. If something appears in red on my screen, I automatically look at it first. If there's to much red to focus on the specifics, I know I'm ...
Other possible solution would be to upload your MS Project file to google drive. Once there, try to open it and a popup will display asking you to use a couple of free tools:
1. Gantter for google drive
2. Project viewer for google drive
Then, I guess you can share the file with your team.
Another option would be to use Office 365 online. In that way, you ...
I do not know how to tease the information out of TFS, however if you are willing to use another tool that integrates into TFS, I would suggest Eylean Board. It offers time tracking as a feature and generates time reports based on what you need. The reports are generated for each team member individually, including all of the projects they are working on.
I would start by asking: What is the report and who is it for?
There's no singular right answer - I don't think it's safe to say that "the Scrum Master should create all reports on behalf of the development team" or "the Scrum Master should create no reports on behalf of the development team".
A Scrum Team contains three roles - Product Owner, Development ...
I generally agree with the two comments posted so far. I can tell you two things that we have used these kinds of metrics for in the past.
Obviously, if you have one area that has a lot of bugs in it, you need to do something to improve development or QA procedures in that area.
You can use the bug closure rate during this phase of development to estimate ...
I've been collecting bug related data for years now, and the number of fixed bugs haven't given me anything useful, because this data didn't tell me much about our projects of effectiveness. It simply says that how good we are at fixing bugs, and doing something we shouldn't have done in the first place.
When I talk about solving bugs I like to use an ...
Excel and PowerPoint-
I've yet to find a single tool that can be tailored to the needs of all the stakeholders. To often I waste a lot of time futzing with the tool and not enough doing real work.
When I joined a company, they had this massive status report slide deck. Less than eight projects being reported on and it probably ran close to 100 slides. ...
I'm not aware of a way to generate this report using the built-in reporting features (even with a custom report format). You say that you can run it on the client -- are you able to run VBA? If so, you could generate this using a custom VBA function.
The Resource View will have the Resources listed in a column. The Row headings can be the time span - days, or weeks or months. For each resource, the projects they are working on will be shown.
Wouldn't this, automatically available Resource View, suffice ?
Don't Give Reports During Scrum-of-Scrums
Your question has a great title that already contains the seeds of your answer, but I think the body of your question obfuscates the issue. You ask (emphasis mine):
How to keep a Scrum of Scrums meeting short and efficient given that reporting on non-technical issues can take a long time?
You are exactly correct:...
We have found it most useful to track the following:
Impediments - who owns them.
Cross-team dependencies - when to expect.
Resource contention - how it was agreed to be resolved.
In addition, you may find this detailed write-up from Mike Cohn of Mountain Goat Software helpful:
Manage it through change control
due to some changes in the way you do the work and other interventions, you estimate that you can shave off the finish variance and actually come in sooner than planned with a favorable variance of four days.
Sounds like a miracle! I recommend a cautious approach. I would hate to communicate an early completion now and go ...
I would highly suggest updating to TFS 2013. They've implemented agile portfolio management tools, with 7 levels of work items. It is currently in preview, but it is fully supported and "go-live".
Here's a good site outlining the new features
The 2012 alternative is to nest PBI's inside of PBI's, and manipulate area paths to simulate various levels ...
Seems like you have a new project. I think the simplest solution is to keep the original PMB as is to maintain as a project artifact and create a new PMB for the revamped product. It doesn't seem like a ton of value to alter the existing schedule.
However, if there is a reason to do so I am not seeing, it is totally appropriate to make old work packages ...
Adding on to what salsolatragus said, in a project environment where deadlines are critical to be met, the application of colour psychology (in RAG, or any other extension of RAG) is extremely useful as it instinctively promotes a specific awareness with less ambiguity (than a scale system), while making it appear more objective. This is useful from an ...