Straw-Man Agile Project Sizing: Part 3


In Parts 1 and 2, I suggested a systematic way to tackle rough software project sizing for budgeting and strategic business planning. You may not agree with my approach. It’s just a suggestion, a straw-man for straw-man estimating. The point is that software projects are sizable even before they’re fully defined, as long as we qualify our estimates. Identify the…

Read More »

Straw-Man Agile Project Sizing: Part 2


In Part 1 we talked about the challenge of furnishing cost estimates for loosely defined software development projects. These are typically initiatives still in the proposal stages, for which business stakeholders need cost before they can determine the potential return on investment and budget. In this second of three parts I’ll suggest specific examples of ways to sketch in enough…

Read More »

Straw-Man Agile Project Sizing: Part 1


Annual budgeting is in progress and the leadership team want to know how much it will cost to deliver on the planned objectives for the coming year. The problem is, the engineering team hasn’t spent more than ten minutes discussing those products or features, and therefore have only a superficial understanding of functionality, or in some cases, no understanding at all.…

Read More »

Dread-free Software Estimating


You may believe that time estimates are useless. You may be correct. Estimates fulfill a specific purpose, predictability, which may not apply to your project or initiative. Any schedule-driven project, Agile or otherwise, hinges on the accuracy of estimates. If you don’t need predictable delivery, you can skip this headache altogether. If you’re lucky enough to work on a product…

Read More »

Story Slicing


One challenge of Agile development is the process of breaking down business requirements from Scenarios into a set of clear and distinct User Stories. Evolving software architectures have forced us to adjust some definitions. Story Craft User Stories begin with a declaration: As a <user/actor>, I want to <do something> , in order to <get some result>. Each Story should…

Read More »

The Date-Driven Project: Cracking the Agile Paradox – Part 4 of 4


Of course we need tools and techniques to successfully manage a project, but we also need agreement among all the stakeholders — agreement on budget and schedule, agreement on functionality, and agreement on rules of engagement. In this series, I’ve discussed some of the advantages and disadvantages of Agile methods, Scrum in particular. Pristine Agile methods are ideal for projects…

Read More »
Rail yard in action.

The Date-Driven Project: Cracking the Agile Paradox – Part 3 of 4


In the previous installment of this series, we talked about scaling application designs and breaking those designs into tasks and estimates in preparation for scheduling. Now let’s take a look at how to go about building that schedule. The Scrum metric for capacity or work completed over time is Velocity. Over several Sprints, Scrum teams calibrate themselves by assigning complexity…

Read More »

The Date-Driven Project: Cracking the Agile Paradox – Part 2 of 4


In Part 1, I discussed some of the realities of schedule-driven software development. We looked at the both the practical business need for deadlines, along with the pitfalls that have tended to polarize engineering teams and their stakeholders. We also explored the two project management extremes: The waterfall method, in which we set a deadline and then identify, analyze, and…

Read More »
Triangle Illusion

The Date-Driven Project: Cracking the Agile Paradox – Part 1 of 4


In this article, we’ll take a closer look at schedule-driven projects, which I touched on in an earlier post, entitled “Feature Driven or Date Driven?” All date-driven IT projects have competing goals, derived from the vertices of the so-called “Iron Triangle:” budget, scope, and schedule, where quality is an orphan (more on that some other time). Anyone confronted with this…

Read More »

Point Deception


Dead Reckoning Story Points originated deep in the annals of early Agile methodologies, before Scrum. Points were meant to address a specific problem: A feature’s complexity is distinct from the amount of time it takes to implement it, due to the widely variable skills and productivity of individual software engineers. Scrum teams use Story Points to calculate their Velocity, a…

Read More »