Hacker News new | ask | show | jobs
by Toss8675309 2363 days ago
Kinda depends on how large your product / project is. I work as a (mostly) solo dev on very large projects that are typically completed by teams of 5-10 and take 6-12 months to complete (even for a those teams).

* Pivotal Tracker is IMO the best agile PM system.

* I break each project into Epics, then down into discrete Stories, basic agile stuff.

* I only score stories at 1, 2, 3, 5, 8, 13. Anything larger MUST be broken down.

* Any story scored 8 really should be broken down into smaller pieces. Any story scored 13 MUST be broken down.

* I use Harvest to track time against individual stories, and require that any subcontracted developer do the same. This allows me to determine for any given dev, including myself, how much actual time a given point weighting equates to.

It's a lot of work to do this at the outset of a big project and feels very waterfallish. And it's tiring to think so deeply into implementation details. But it's very much worth the effort.

My personal pattern is to whittle the project down in multiple passes. So Pass #1 is just breaking things into Epics. Pass #2 is breaking the Epics into 8 or 13 point stories. Pass #3 is breaking those 8/13 pointers into 1/2/3/5 stories.

I absolutely do not open an IDE until this process is done. It's so tempting to just start writing code. Avoid that temptation. :)

1 comments

> I absolutely do not open an IDE until this process is done

How do you deal with changing requirements? Or when your understanding of the problem changes midway into the project? I find that one or the other happens frequently. It's nobody's fault (most of the time), just the result of the reality that customers don't always know what they want and are frequently unable to accurately communicate what they want.

Oh that happens all the time, sure. I'm referencing what I do at the start of a project.