Hacker Newsnew | comments | show | ask | jobs | submit login

We hesitate to put non-technical tasks into pivotal and assign them point values. We've found that changes our development velocity, which is not desirable.

The other big issue is that our process is about setting out two or three things we want to do in a day, and seeing if we can meet our goals.

It would not make sense to click the "start" button on three features/chores/bugs at the beginning of the day, because again it would skew the pivotal data.

Arhh yes. For the sake of brevity I didn't get into more detail on how I've done this in the past.

I've experimented with both using a separate project for non-engineering (to avoid the skew) but also simply including non-dev work into the velocity with the same rigor that items that offer true value get points and 'cost of doing business' (pay server bill, write documentation) are non-point-accruing chores.

Both work for me.


I see where you're coming from. If you're tracking tasks at all, you're doing something right. However, if you use pivotal for task management, you can't estimate how much you'll get done in a day. It's not like a developer can press the start button on three features, even if they want to complete three features in a day.

Our technique is about setting out a good amount of work for the day, and trying to meet those goals. We pull few chores/bugs/features from pivotal and throw them on the board all the time.


Applications are open for YC Winter 2016

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact