I became a huge fan of the Agile development methodology over a decade ago while working at Lumos Networks as a contract PHP developer. This is also where I learned Test Driven Development (TDD), and have much to thank Brian Johnston for bringing those skills into my toolbox, even after many years. And they say an old dog cannot learn new tricks. But up until then I have worked at places which were strictly waterfall, with massive Gantt charts which covered months or even years (Teletracking being the latest), places where we used the Spiral Methodology, where we had three large teams alternated between stages of design, coding, and testing where each stage lasted 3+ months (Bell Labs), and places where we had lots of smaller projects which were pretty much waterfall, but everybody was mostly working on the main project, with maybe a second project running parallel but independent of the main one (and may or may not using things like Gantt charts). And others, like Monkey Knife Fight, were "sprint-like", where every M/W/F we met briefly to discuss our projects, like the brief "stand-up" meetings Agile embraces, but we never formally did the planning with estimation or retrospectives.
At Lumos, where the entire company was Waterfall, our group tried to do things differently. While corporate expected Waterfall, complete with project estimations (often made on fuzzy, incomplete requirements) which were expected to come in within ±10% on hours, else we had to re-estimate and get dinged, internally, while I was there, we transitioned within the team to using Agile with weekly sprints, where we would take the project estimation, break it down into larger Epics, smaller Stories which represented things we estimated would take a single sprint (week), and then as we neared working on Stories, got broken down into tasks, assigning what is supposed to be a abstract unit, the Story Point (which typically follows a Fibonacci sequence), to represent each Epic and Story, and every individual task is supposed to represent a day or less of effort (you try never to have a task last into the next day, even if it means an ad-hoc splitting it into two parts). Those may have been in hours, as they typically are, but this was almost ten years ago. And when estimating points, the team normally gets together regularly for planning sessions and "votes" (it is often called "Planning Poker", for a reason) by calling out the number of points for a story or epic, with discussions about the outliers. The key is, you all do so without knowing what the others are going to say. For this, some teams have an actual deck of cards showing 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, and 100, sometimes with a "?" for when the team member doesn't understand the requirements, a coffee cup when the member thinks a break is needed (planning sessions were supposed to run less than an hour every other week for us, while others may run 2 hrs for a one week sprint, and others may spend 8 hours planning a 4-week sprint, though that rarely happens), and "∞" (the infinity symbol) for something which is far too large, poorly defined, or complex to be estimated. In that case, sometimes it gets broken down a bit during the standard planning session, or it might be broken down a bit by a sub-group "offline". And one problem that teams have to watch out for is trying to equate story points with hours. That can vary from developer to developer and task to task. We had some 8 point stories which ran a full week, and other weeks we might knock off a 20 point story. As you might guess, this makes estimating actual hours, especially months or a year or more in advance exceedingly difficult. Indeed, when I left there (because we had been acquired, and the acquiring company got rid of all contractors), we were (with management grumbling quite loudly) on our 3rd re-estimation of a project which had initially been estimated at over 2 developer years at the start, and which grew because the requirements were mostly unknown.
Also, a quick aside. Some readers might not realize that n reality, the idea of a "developer time" unit is pretty much mythical. If you throw twice as many developers at a task, it doesn't always equate to getting it done in half the time. Indeed, sometimes, it increases the time because of churn. It can be like the saying "too many cooks spoil the broth". And when you are talking a project which will take multiple developers a year or more... hopefully you see the problem. And no, on that project I mentioned, this was not the case. It really was that when we estimated, neither the engineers who managed the switches or our team understood what it would take. We had only had one of these a month or so for initial testing, and had not even settled on how we wanted customers configured, or even what it would take to setup certain types of circuits.
The reason for this long intro is that I came to favor Agile over Waterfall, in a huge way, and even more so for large projects. No matter how hard you try, be it multiple people spending 3 months of planning writing designs/requirements for roughly 3 months of development and 3 months of testing, or trying to estimate a project which might take 2+ developer years, I can almost guarantee that your time estimates will be wrong. And while things like GitHub issues are great for tracking the bigger things, like bugs or new features, it really sucks at helping break things down into smaller chunks. And that is where things like Jira, VersionOne (what we used at Lumos) or tuleap come in.
That's a rundown as for why I have been messing with tuleap. In the next part,