1

I've just started freelancing and have two projects where I am splitting my week with both companies, one I'm charging hourly and everything is fine, the other one however they have said they will pay me based on a points basis using Pivotal Tracker.

For example, there's a fixed rate per point and they work on an estimate that I will complete two points per day, I was just wondering if this is something that is used regularly or if I should try and get them to switch to hourly?

My concern is that points are only used for features and if a feature has a bug this isn't taken into consideration so any time spent fixing that bug won't be charged. Correct?

  • 4
    "My concern is that points are only used for features and if a feature has a bug this isn't taken into consideration so any time spent fixing that bug won't be charged. Correct?" - ask the company you're working for. We can't possibly know. I don't see why you can't assign points to bugs, so you also can get paid for fixing bugs. You just have to make sure you and the client agree on this. – CodeCaster Dec 12 '13 at 12:31
6

they have said they will pay me based on a points basis ... I was just wondering if this is something that is used regularly or if I should try and get them to switch to hourly?

Whether this approach is common or not doesn't really matter, it's what is being offered to you.

Contract work is usually hourly or by per-project. For example, if framing a house the crew might be paid $X per hour or they might be paid $ABC total for the project.

The second company is offering you a variation of the per-project approach. Their projects are variable in size and they are using points as a means to assess the size.

Switching to per-project shifts some of the risk of the project onto the contractor (you, in this case). The company is saying "we'll pay $ABC total for you to do XYZ." You have to assess the risk of being able to complete XYZ in a period of time that keeps your earnings at a reasonable level.

This can work to your advantage if you're really quick at programming. If you complete the project in less time than they expect, then you are effectively paid more per hour of work.

This can work against you if the estimates are off or you run into unforeseen problems. Your effective hourly rate will be lower in this case.

You need to think about how accurate their estimates are, what the quality of their code is, and how well you can work within their code base.

My concern is that points are only used for features and if a feature has a bug this isn't taken into consideration so any time spent fixing that bug won't be charged.

Not necessarily. This is something to negotiate with the company. In other trades, per-project contracts often have an "extenuating circumstances" clause that allow for an hourly time-and-materials rate to be charged when unforeseen problems occur.

In this case, the sooner you can identify problems the better. You want to be able to raise the issue prior to investing too much of your time that may not be compensated.


Whether or not you should accept their per-point offer depends upon how comfortable you are with the risks involved. It also depends upon whether or not you think you can make the circumstances work in your favor.

You may not have a choice either. The company may not be willing to negotiate. And if that's the case then you'll need to look for contract work elsewhere.

1

This is a question that has two aspects to it: How you deal with your clients, and how your clients deal with your work. The first is a business aspect, the second is a matter of QA.

I'm going to be somewhat optimistic, and assume that there's some way that they approve your work when you submit it. If there isn't, make it happen. This provides the basis for a stable working relationship, as it will make clear to both parties what it takes to work together and when things are going satisfactory.
Being an independent professional includes bargaining on stuff like this. You need to be able to function, otherwise you're paying for their incompetence. (in terms of Quality Assurance and Control)

I'd have to say that with a pay per task system, you're initially taking the burden of risk when it comes to bugs. That means that you have to plan for them, as they're inevitably going to happen. It also means you have to do a bit of your own QC and QA before you submit your work for approval, to minimise the risk of failure. Keeping track of your failure rate will improve your accuracy when it comes to making a good estimate on how long it will take you to complete a task until it has been accepted by the hiring company's QC department/process. Also, you need to make sure that a task is specified in clear and completable goals. (SMART)

If the client has no QA process whatsoever, then you're in trouble. If there isn't some kind of QC during acceptance, then there's no transfer of responsibility. You're stuck with the bugs until they're gone. This then enables them to play the blame game, forever. Some basic QC should take place upon accepting your work, or on a complete body of work that you have delivered (not points, but complete products/parts) that you deliver. Each task is like a mini project, and needs to be treated like one.

Now, if their QC has passed your work, it's up to them. If they throw it back on your plate after having accepted it before then it's a new job if you ask me. But this really is something that you and your client should have agreed on before commencing work. Maybe you need to (re?)negotiate this bit with your client.

As for x the points per day, that sounds like typical SCRUM-type agile work provisioning. I wouldn't have a problem with it, as long as your own estimates don't differ too much with theirs. It would help if you had a say in the estimate, but sometimes that's just not your call.


Some side notes on QA and QC:

  • Quality Assurance is the process that ensures quality in the processes that are used to develop software. e.g. Planning that you will do quality control, process evaluations and and how to improve processes after finding faults.
  • Quality Control is what you do to check that the product is doing what it is supposed to do. Things like setting up a unit test for a specific project etc. (including all the planning that is required to make it happen)

A company without a QA process is likely to have failures, which will probably mean that their code is likely to be buggy. Your code that has to integrate with it, and could suffer because of it. Implied QA is usually the same as no QA, as it's lacking structure, and therefore process improvement is very hard. (if not impossible) Having QC without guidance is then just a way to make it look good superficially.

QC should be the result of QA. There are a couple of systems that can help improve QA, like CMMI and SPICE (ISO/IEC 15504)

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