July 20, 2017
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…
July 20, 2017
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…
July 5, 2017
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.…
June 14, 2017
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…
January 9, 2017
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…
December 13, 2016
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…
December 8, 2016
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…
November 29, 2016
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…
November 15, 2016
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…
October 23, 2016
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…