Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have a problem on reporting progress to my employer. I am a part-time programmer, handling a software project for my school's (non-technical) department.

Contact person:
1. The staff who actually uses the software and raises feature requests,
2. My boss (non-programmer), and she is not the software's user.

The project's nature:
It is a ready-made software, which has been bought from third-party. I have to modify or add feature/function to this software in order to cater for department's need. This is a software is need to use throughout the semester. Not all features needs to be used at the beginning.

Hence we are using the Agile model: When the staff needs a certain feature, they raises a request, and I make the changes. By the end of the semester, I suppose all the required features will be raised and implemented.

The problem:
Everytime my boss asked me how the progress, I can't answer, because I don't know how to answer. I don't have complete list of all the required features. Even though I have completed features which were raised last week, I still can't tell my boss I have "completed", because new features are coming in too, and I don't know how much. I can't tell "We have how many % completion" nor "We are going to complete it by xxx". Sometime out of 3 requests, I manage to complete 2, I would tell my boss "I have completed 2, but there is one feature not complete yet". After a long period of time, I sounds like "I always have something not finish, after so long".

Being unable to report the progress makes me looks really bad. It's not about how much I've done, it's about how to let people know. If I were the manager, and my staff keep failing to report the progress to me for months, I will feel this guy is incapable too.

Do you guys have any idea how to report, or answer question as simple as "what is the status / progress of the software modification"?

UPDATE My boss doesn't involve in development task directly, so she doesn't have a clue on what I am doing, or how the program works. We don't meet regularly as she is busy, and I feel it will be waste of time because she is not the main user, she doesn't know the detail of the program.

I meet regularly with the staff who uses and knows better about the software.

I feel hard to explain the progress to my boss.

share|improve this question
add comment

8 Answers

up vote 19 down vote accepted

This is a common problem when you're a programmer who works independently, and you report to somebody who's not technical.

Bosses like that mostly want to be able to figure out a few things:

  • How happy are the users?
  • Are the things the users want getting done?
  • Is what you're doing worth the money you're being paid?

An Agile burn-down or anything else like that would be a terrible idea!As you said, your boss is really busy, so they wouldn't have time to learn about it, and probably isn't interested in it anyway.

So if I were you, I'd email them a report once a week containing:

  • An "executive summary" at the start: "Finished 3 features this week, and got 2 new feature requests. At the start of this week, there were 11 unfinished feature requests, and at the end there were 10."
  • A feature status list, with a brief sentence each, in three groups:
    1. The features you got done during the week
    2. The feature requests that came in during the week
    3. The other features in the "backlog"
  • A brief discussion of anything that was complicated or unusual, preferably using non-technical language.

If I were your boss, and I hadn't been getting any reports, I'd be very happy to get that every week. And if I wanted something different, I'd ask you for it.

share|improve this answer
+1. The email would also be useful to everyone, not just the boss who doesn't appear to have any project number. All managers like a task list going down. –  G3D May 26 '11 at 10:44
Yeah, this sounds very sensible. Also ask, where are you going long term -- is it enough to keep fulfilling feature requests in some sensible order? In which case, just keep doing it. Or would it be better to try to save some time to look ahead and say "will we reach a point where the software is more 'complete' than it was" or "we should abandon a number of these feature requests and fold them into some more extensive change"? If so, you may need to figure that out for yourself, but also tell boss. –  Jack V. May 26 '11 at 12:41
Key here is know your audience. Speak their language. As the answer stated but its very important to be as succinct as possible giving them information that actually means something to them. She may just want to know that your working. It's hard for someone in a position of authority to not have a clue as to the voodoo that you do. –  Ominus May 26 '11 at 14:41
I originally had this in my answer, and on reflection I think this is better. It's simple and makes it easy to understand whether the backlog is improving, or getting worse. –  Joe McMahon May 26 '11 at 23:33
I would consider adding a "notes" or similar section where you can comment on the interaction with the users along the lines of "Users seemed delighted to have feature X added to the system" or "Recent requests have focused on the XYZ part of the system". This will give your boss some basis for conversation with the users if it comes up. Creating an opportunity for her to informally discuss the app with your users should help her comfort level with your progress. –  TomG Dec 10 '11 at 4:52
add comment

It sounds like you have no way of knowing if you are complete or how far along you are to completion. That is okay.

Keep a list of the features requested, which ones are done, in progress or not started. Track these as week to week chart of the total in each category. This will give you a set of points that you can extrapolate to the end date. That is (looking only at "completed" feature counts)

  • Week 1 - 2 complete
  • Week 2 - 5 complete (2 from week 1, 3 from week 2)
  • Week 3 - 8
  • Week 4 - 12

If you have 16 weeks, you can complete about 48 features (don't worry too much about some features being bigger/smaller than others, after 4-5 weeks it will generally average out). You can then report to everyone that you only can handle X number of features. At the end of the project, what is absolutely the most important thing is that you have delivered the features needed and you haven't killed yourself in the last two weeks. By reporting this way, you can pull the key requirements out as soon as possible.

The other thing you will want to report is how much capacity you have. "I only got 2 feature requests, but could have handled 3... can you ask the staff to raise more features sooner?"

not sure I completely answered your question, so feel free to ask follow up questions...

share|improve this answer
add comment

Three words ... burn down chart.

Your employer, whether or not they are agile addicts or just a person in charge of developers will appreciate a burn down chart.

Everyone loves to understand when a project will be completed and leveraging yesterday's weather will provide the most accurate and most realistic way to predict the completion of a project.

share|improve this answer
I would assume, in order to make Burn Down chart works, I will have all feature requests at the beginning for each month, and the chart is showing trend of one month progress. My feature requests come in every week. Should I make BD chart for each week? It looks weird by only showing 3 requests (for example) for each week. –  Janet Smith May 26 '11 at 3:10
For a burn down chart to capture the work properly, all the stories for a release would have estimates associated with them. The total sum of the estimates represents the total number of points for the release. Then, as a story is completed, those points are represented on the chart. It's ok to add new stories at any point in time ... those stories just wind up increasing the total number of points. –  Dakotah North May 26 '11 at 3:16
A Burn Up chart would be able to show progress even if feature requests keep flowing in. –  rwong May 26 '11 at 4:55
add comment

I'm assuming that you do a one-on-one at least once a week, and can discuss your priorities with you manager at that point - what's important from his/her point of view (so-and-so needs his feature before other-person, etc.) - and can therefore report how much of the stuff that makes your manager look good is done vs. the amount of stuff you have in total to do.

Your manager is probably not looking for a minute-by-minute breakdown; s/he's just trying to see if the work is getting done, if the important things are getting more attention, and that you're not drowning under the load or idle because you're blocked from proceeding.

Note that in a true agile process, you do indeed have stuff coming in all the time, but you and your manager agree on what's most important/most needed and how much of it will fit in the current work period (whether that's a week, two weeks, a month...), breaking the jobs down into smaller pieces if need be so that the pieces will fit into the period.

A major database overhaul taking several weeks could be broken down something like this: establishing backups, verifying the backups are good, designing the new database layout, writing the conversion software and testing it, setting up the rollback and testing it, trying the conversion on the staging machine, trying the rollback the same place, and then finally doing the conversion. Each one of those can probably be broken down into 1-week (or less) chunks. If some steps might take 2 or 3 weeks, you'd report how far along you were in the next meeting (targeting 50% for a 2-week, 33% for 3-week, etc.).

Ideally, you'd have a chart that has the stuff you need to do vs. the stuff you're going to do now, and you'd check off the "do now" items as you're going along. This lets your manager just walk by and see how many things are marked off vs. things that are on the list to do.

share|improve this answer
I believe the manager you mention here, normally involve in the development directly, and assign task. My manager doesn't get involved in development. I've sent her gannt chart before, but it doesn't help, because I've broken the tasks down according to features. She doesn't know the detail of the project, so it may seems overwhelming to her. –  Janet Smith May 26 '11 at 1:56
I'm thinking of the "burndown chart", like this one. Note that it shows how far along you are, what you've gotten done (the "must haves" at the top, the "nice to haves" at the bottom), and gives an idea when you'll be "done" with the work you currently have. You'd need to shuffle around the right-hand column (the one the "we are here" arrow points to) as you add work. You should still have the one-on-one with your manager to to make sure the right-hand "how important is this" column is in the right order. –  Joe McMahon May 26 '11 at 23:26
add comment

Once every week (I assume that the length of iteration/sprint in your agile process is one week for the sake of example), do the following:

  • demo the new work to the staff, to make sure their requests have been completed
  • report to the boss the number of requests you completed during the week and identify/describe those requests. Make a short summary
  • report to the boss the number of new requests added to your backlog/queue during the week and the total number of requests
  • tell the boss what (which requests) you plan to work on next week; in other words, the current priorities. Here's the opportunity for her to confirm or change them and for you two to be clear on that
  • tell the boss what the plan is for 1-2 weeks after that.

I sense that your boss is not technical enough to care for or understand agile terms like velocity, product owner or burndown chart. The above template avoids such jargon, uses simpler words like "backlog" and "queue" in their common sense, and should thus make it easier to communicate with your boss.

share|improve this answer
add comment

I would use my velocity as the primary statistic to him/her. This will show how many tasks/features I "agreed" to talk for a particular week (or other timespan) and how many I completed. From this, I would mention some of the more important features implements, and why this has changed from past iterations. You can also mention any impediments that you encountered and surpassed and how that effected your velocity.

Other statistics that your boss may want to know about could include number of new bug reports raised, bug reports closed, and new feature requests submitted. You will have to either ask directly or use your best judgement to determine which ones are the most important. In the end, I would give a basic outline of progress and ask if there is anything else that he, or she, would like to know about. All the boss wants to know is that you are making progress and is there anything that you need to work your best.

share|improve this answer
add comment

Suggest you commit weekly report: List the requested features. Record the changed features. Report what you have done.

share|improve this answer
add comment

I would try to bottom line it in a manner that managers understand.

Total Recieved Feature Requests:
Requests Completed:
Requests since last Update:
Estimated Time to required to complete remaining Requests:

Just because your manager is not a programmer do not think that means they expect you to know an exact completion date. Present the numbers you have. After the manager sees the numbers of requests recieved and completed going up the manager sees progress. If your requests numbers get out of hand the manager can step in and help you out by prioritizing before you are overloaded. And if you are running out of work to do they may be able to find you some small side project. After all its always nice to get a bit of a break on a project when it seems there is no end in sight and work days go by faster and are more rewarding when you are busy.

share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.