You can commit to iteration planning by doing commitment-driven Sprint planning or by doing Velocity-driven Sprint planning. Okay, great. What if I do not know the Velocity? What if I do, but still don’t know how to plan the Sprint because I cannot determine how important each Story is? And then, what if those stories disaggregate and we have more stories… multiplying like rabbits and everyone is saying that each one is “critical” or “oh we *definitely* need that one…?

I had what I thought was a pretty slick method, but the truth is I was always refining it. It had to do with Value, of course. It looked something like this:

• Business Value (1-5) or 100 if it is something we cannot go live without
• User Value (1-5) or 100 if it is something we cannot go live without
• Technical Difficulty (1-5) or 100 if it is something we think is akin to magik in the deep woods of The Black Forest

You add these (after applying a multiplier if for instance, User Value is 20 percent more important than anything else) so you get something like this:

UV = ((2.3)(1.2)) times BV (3.2) times TD (5) equals 44.16

This would usually (or could) be the end result of a Faceted Feature Analysis (FFA), where the Product Owner does not name all the values themselves all the time. I would encourage them to ask stakeholders for their values and then do the classic Planning Poker thing. “Jane, you say having a stock ticker is a 5 and Bob, you say it is a 1. The rest of you are 2 or 3. Jane, Bob, can you explain why your values make sense to you?” Then, final voting. Depending on the circumstance you may want to document (if you have to) that Jane and Bob still did not agree or maybe they did not realize and will agree to a 2.5 or a 3 or whatever it works out to. The goal is to get that final number. Also, if that number is over 100 you really need to examine it. What being over 100 is saying is that this is a major deal, and might require more exploration.

Of course you also get the Technical Risk this way. I like that because high value, high risk stories are identified early and you can play the Fail Fast game. Lots of people want to implement the low risk and high value stories first, but since something like a third of features built are ever used, it makes good sense to figure out as soon as possible if something cannot be done, if part of that something is good enough for now, or if holding onto it like Linus and his blanket would only mean you cannot swim when you are in the water of the project.

BigVisible presents another way, which is simpler, and I like for other reasons:

They talk about the Kano Question Form and Kano Analysis. I will do that later, since is would be a tangent on the theme here.

They use what I will call the “Nines Approach” (or at least they proffered it along with the disclaimer that it is not THE ONLY way).

Looks like this:

Which one of these is right? Both. Neither. What is right is the third way to assign Priority: be Agile. The second method makes it a little harder to Fail Fast without some conversation, but that is actually good: you *want* the Team to talk.

In some situations the first approach or the second approach may speak closer to what your team understands and likes. In some, it will be a balance of the two plus or minus a Tradeoff Matrix. Some will want to see a weighted Feature Prioritization. Some will not care as long as the Product Owner or *someone* tells them what the goal of the Sprint is.

Thanks to Big Visible, Giora, and my wife for helping me with some crazier ideas that will be in a future post.

Best,

Josh Milane

There are a few, but then I stumbled upon this page on the dropbox website and I think it is brilliant… especially if they are doing certain things behind the scenes. They are already working their forums so that if a person asks a question but is really asking for a feature, they direct the user to vote for the feature. Anyhow, this is great in my opinion.

Simple idea, but how much info they get from this!

Best,

Josh

If you take a look at  you will see that the author proposes a checklist as a tool for projects. Great. He does not say if it is all inclusive, what kind of projects it is for, and he does not really commit to much, which is why I wanted to comment on it here as I put off doing some light housekeeping. The bird’s next over the fridge should probably go outside, and even though it was a nice day yesterday, the doors should likely be put back on the house.

The below is copy and pasted. It is a list, so if the author min.ds terribly, please just email me and we can talk about it. I have sent you a note.

From http://www.projectsmart.co.uk/project-management-checklists.html

Mr. Vaughan is in italics, because it is cute, and I am in regular bold type, because I am regular, but a bit bold.

Among all the tools at our disposal for managing projects, checklists are perhaps the simplest and most productive means of building consistency in work practices. Checklists are useful in almost every field of human endeavour, and in particular where repeatability and systematic action drive performance. Yet they are still much underused in the planning and managing of projects.

I am not sure that they are so useful except as transient artifacts that speak to an audience ready and willing and able to take value from them.

Here is a high level twelve-point checklist for use during project planning:

1. Have the needs and concerns of all key stakeholders been considered and resolved?

I suspect you know I will say that it is impossible to address all concerns of all stakeholders during planning. If we are planning iteratively, we certainly have a better shot. If we are delivering incrementally, we have a better shot, but to have anything more as a goal is to state something as a goal that will just not be achieved. If you have ever tried to have all Stakeholders resolve their differences before anything gets built, I expect you will either get a few angry stakeholders or have never heard of the Product Owner role.

2. Does the project have an overall approved mission statement defining the scope, schedule and resources/budget?

As long as we know it is going to change, all we can really have at the beginning is a Vision. We can certainly have resources and a budget, but resources change (people get hit by buses, I hear) and I would rather deliver under budget which makes the budget less important as our goal, which will of course potentially change. The epic may remain, but functionality can be phased, shelved, pushed to V2, or any number of things.

3. Has the relative flexibility among scope, schedule, resources and budget been determined?

I am surprised to see reference to what sounds like a Tradeoff Matrix here. Most of the time, however, in my experience this is better done as you go than up front unless you are following a Faceted Feature Analysis approach (and there are better ways to Prioritize, I think).

4. Have all project deliverables been identified and described in detail with unambiguous completion criteria?

Holy Mackerel. Really? Before we start building? This can be done, sure, but what parts of this have real value.

5. Are roles and responsibilities defined and agreed upon for all project team members?

This also many change, but you do have to start somewhere. I would rather define roles and have people fill those roles as required in something like a Kanban model or a Scrum Team that really works like a team, but Mr. Vaughan may agree.

6. Has an appropriately detailed work breakdown structure (WBS) been created with input from key team members?

BRUF. Muda. Can throw a million buzzwords at this one, but I will just ask if the project after it has been delivered ever even once looks like the WBS when done up front. I am biased and although I have created my share of WBS documents, I look back and wonder why, except that the whiteboard looked really slick and people tended to assume that I knew what I was doing. Throw some compliant UML up there and you are almost untouchable by critics.

7. Has a credible schedule with identifiable critical path and late schedule been developed from the WBS and optimised within the project constraints?

See #6. If you have done this, you have not only wasted time, but you have straitjacketed your product and your Customers or Stakeholders are not likely to be happy filling out Change Request documentation.

8. Have milestones been included in the schedule to track major events, completed phases and/or deliverables and external dependencies?

Milestones are great, but can we be flexible with them? If so, lets do that. If not, lets see what the definition of that milestone really means. We may hit August 19 and hit the end of a “phase” but gotten nothing done unless you take a more Agile approach and do not attempt to be Karnak the Magician or whatever the guy on the Johnny Carson was called.

9. Have workload commitments been identified for each week of the project and agreed to by team members and their managers?

Every day, in a standup, you mean as well as in Sprint Planning or within the pull of Kanban? I like the idea of commitment. I don’t like the idea of Management setting definitive workloads for the developers.You get overworked, under-appreciated, burned out developers that way. Happy employees get more done than disgruntled ones. Some disgruntled ones come to work with a rifle. Yowzers. Still, the rifle does not worry me as much as this seems to be calling for huge amounts of effort and a constant team with constant velocity.

10. Have response plans been developed for the most significant threats to project success?

Risk Documentation. Exposure can change as you go, but a valid response to a high value item once it has been attempted and proved to be very very difficult and to jeapordize the sprint may be to break it down and employ disaggregation it or put it off until the end. Fail fast. Go after the high risk, high value items first.

11. Has a change management process been defined and agreed to by all key stakeholders?

How about talking every day and constantly re-prioritizing, reshaping, being realistic instead of doing a big fat Big Up Front Requirements document that nobody will ever read along with any number of thick unreadable documents that this approach seems to call for?

12. Has the governance structure for the project been established with an agreed sponsorship role and expectations set for review frequency and format?

I agree that you need structure, but words like governance imply a formality and inflexibility that I think you might wind up needing. People take vacation. Even if you do take OOTO time into account, if your Customer is part of the team and iterative work with incremental delivery is your model, it would seem to me that this will work itself out.

One of the features of checklists is that they can be designed to extend hierarchically, such that a sub-checklist could be developed to facilitate any or all of the checks above (e.g. a stakeholder analysis checklist or a risk management checklist).

Uh oh.

The PMI, training firms and PMOs would do well to promote checklists more strongly – project managers like to use checklists; not many want to read through an overweight methodology. And managers like checklists because they improve quality and instil consistency.

Just as it is in the best interest of the Scrum Alliance (just ask Scott Ambler) to create the CSM certification, it is probably in the best interest of PMI and PMPs to cast a spell upon this as the approach you should use. I encourage the opposite. Try different things. If you have only worked for large companies you likely have not seen the amazing things that can happen in small, empowered teams. Putting people first is in the best interest of everyone.

Thanks for the ideas. Again, the above was a response to http://www.projectsmart.co.uk/project-management-checklists.html. I only disagree to engage in dialog. If all I did was spout what I THINK, I’d be a blowhard. Let’s talk privately or publicly and I promise, if you get me to see things your way I will be happy to have been wrong. It is in MY best interest to be as good as possible.

Best Regards,

Josh

Directly inspired and partially stolen from BigVisible Certified Product Owner training (with permission, and changed)

PMPs love percent complete. Although it is an illusory measurement (things change!), you will still get requests for the statistic. Here are two ways to provide what I feel awful encouraging

1. Plain old Metrics

Take a peek:

The above is pretty easy to understand, but the percent complete field comes from the total number of story points in a given feature (the pure sum of the points belonging to stories within a feature) and the number of points for features that have had all stories complete. There is your number, viola. Is it accurate? As long as nothing is added to the feature, sure I guess it is as accurate as anything can be given context. Better question might be “is it wrong or misleading” and the answer would be “depends, but you are not lying or misrepresenting what you are being asked for.” If I ask you to poke me in the eye, you might do a really good job at it and blind me, but does that mean you completed a valid task? Depends on who you ask, their mind state, their goal, and a number of things but overall – yeah, you did. Thanks a lot.

2. Colors… mmm… (not the movie nor the song where “I am a nightmare walkin’, psychopath stalkin’…” because I am not. Just like RGB values, you know… the whole Color Wheel thing?)

People like colors. With this method you get not only more detail, but what might be a more accurate (or complete) view of what is complete. Your “not started” line will look smaller, but that is not a function of misrepresentation, only of the technique. “In Progress” might mean it just started or that it is almost done, but it is just a tool.

Something besides Excel would be better than this, as the legend states (maye an .mpp although your PMPs might freak) because your Story Points could be numbered left to right with a degree of accuracy that I cannot provide at the moment. Again, the goal is the same. You get block which represent features but the WIP (Work In Progress) exists as something real and tangible. For the overall Epic, you could in theory have a giant list of these that together spelled out the whole schebang and I do expect this may only serve to elicit “so, how close are we?” at which point you can either stare like a gopher who just popped his head out of his hole or be almost as cool as a quick draw cowboy and whip out the first diagram.

Satisfy your stakeholders but remain honest and educate without preaching.

This was Percent Complete, which is a side effect of estimation and not all side effects are bad. Next, you can expect something on Prioritization. I actually really dig Prioritization.

Best Regards,

Josh

I forget who said it, but I will find out I am sure, that when a Client asked them how to have fewer bugs in their code and how to create less defects, the person responded “Build less stuff.” Pace is going to be a common theme in any development effort with Scope. Pace is subject to all kinds of theories, including my own (which is really a mishmash of what other people have said and what other people have did – I cannot pretend to have walked down the mountain with stone tablets dictating the Commandments of Building Software and I think the Agile Manifesto – the first page at least – is common sense).

Yes, a lot of this stuff is simple but taking the simple and fine tuning it for a specific environment takes discipline and skill. The traditional project manager blankets a methodology over a project and tucks it in here, loosens it there. They are nervous right now, except in large organizations where silos hold the place up (and those same places will be overtaken in my opinion by leaner, more Agile, more realistic and “human” organizations).

I am already displaying my prejudices. It may be important to note that I am going to write this with all prejudices towards Agility aside, to the largest extent that it is possible to not have an opinion. I will try to say what is my opinion and what is not only my opinion but what is established as a kind of “industry fact”. Agile, in my mind, is undergoing a bit of a transformation at least in part to Mark Kennaley’s book: SDLC 3.0 Beyond a Tacit Understanding of Agile. I cannot recommend the book until it is released with legible figures and diagrams, but Mark is working on that and we have discussed that. It turns out that the “Waterfall” approach is an erroneous interpretation of a paper from the 70’s. People were developing in an Agile, or at least, iterative, fashion a long time ago. It is just that Agile was not commoditized or productized like it is today and that (and this is my opinion) the OO development tools that were of the “Visual” nature like Visual Basic and PowerBuilder make iterating that much easier. In fact, OO (object orientated development as a whole) made it 956 times easier (that figure is mine, not a standard) to write code in an encapsulated manner. Either way, methodology will not come into play for purposes of this article. At least, I will try to not assume one or the other before going down a mental path. As a side note, mostly for Scott Ambler, I do not think that calling someone a Certified Scrum Master implies super powers any more than calling them a Scout Master or Master of Ceremonies does. People are not silly enough to accept things without asking questions, although I have had HR approach me saying they want a CSM with 10 years of SharePoint 2007 experience. HR is a different animal.

Before I get too much into bug/issue tracking, it might make sense to address testing, since testing is supposed to prevent bugs or catch them before they manifest as expensive problems. The common way to estimate how expensive a bug fix is involves two approaches: with a live system, what is the cost of the functionality not working. On a live or new system: basing the cost of a bug on which of three phases it is found in: design, development, post-deployment. A $100 bug caught in Design will cost $1000 to fix during development and $10,000 to fix once the code is deployed. This is the most conservative of all estimates I have heard, with the more contemporary views showing that a bug caught post-deployment is 800 times more expensive to fix than if it is caught during a true unit test in a true iterative test-driven SDLC development methodology. These figures obviously depend on architecture and the nature of the bug as well as a bunch of other things like dependencies, available resources, how many cooks are in the kitchen, etc. Either way, this basic idea of determining the cost of a bug (or a feature) depends on abstracting data that is gathered from metrics gathered during discreet project phases, as well as “sizing” the effort involved and even developing against specs while delivering against specs that have a value assigned to them, but that has not been the case in any obvious way for the initiatives some organizations I have worked with have led, as far as I could see. There are “iteration zero” tasks like environment setup, but even these have been problematic. I would point to the lack of internal planning and vendor management (demanding value is demonstrated) as the culprit. I would suggest that a proper Discovery phase was not executed, and that Agile is not figuring things out as you go; Agile is about moving forward as soon as you can, with knowledge, and eliminating waste.

Projects have thousands of pages of Requirements Documents, but Design is not Requirements Documentation nor is Discovery. 999 times out of 1000, the final product does not reflect anything besides “broad and shallow” Requirements Documentation. Even then, what is that statistic? Only something like half of the features in a software product are ever used once the application is up and running. A big reason flexible methodologies are getting traction now is because if you look at a project plan on day 1 and then look at the project plan as it actually happened once you are live… chances are there is almost no resemblance beyond the Phases and the fact that they started, worked, fixed, and eventually finished (not always in that order). This is my opinion, but again rests on the reasonable assumption that software designed to obviate bottlenecks, waste, and to track change makes those things easier to do. The larger the project gets, the more dissimilar the “Soothsaying GANTT” is to the “GANTT of Reality”. Kennaley refers to the idea of “Big Requirements Up Front” or “BRUF” as “perishable goods”. He is an IBM guy, so it is very meaningful to me that he would say it. Regardless, as pointed out in my most popular article, the major schools of thought share quite a bit in regard to structuring projects (and I happen to disagree with myself but leave it up anyhow): http://mittechnical.com/steps-towards-creating-a-custom-project-management-methodology/2007 – the common thought has been to track every requirement and have traceability matrices, but the rug gets pulled out once you realize that things change. Inevitably.

It would be easier to win the lotto twice than to do a high fidelity project plan for something more complex than a simple brochure site with complete OOTB functionality. Even in unit testing, we have to realize that it is not “eyeballing” the code and that there are tons of tools out there to help us. Ask your friends which they like. Ask them to show you how to use it. See if it does not make sense to you and see if they find it useful. Unit testing is often “well, we just write good code and we know because we comment it and look at each other’s stuff”. This is a horrible mistake and the foundation for sinkholes down the road. For Java applications, J-Unit is the most commonly used tool. J-Unit and Cucumber (Behavior-driven development tool, not the vegetable) makes some developers have epiphanies that are amazing to watch. For .NET projects, N-Unit is the most common. It is simply a matter of being aware of them. I have yet to introduce a developer to these tools, or Test-Driven Development / Behavior-Driven Development and not had them fall in love. Once they did not like it. One individual did not. He wound up losing his job because he was by far the least productive, stuck in his old methods. I do not blame myself for that. If you get a tool that helps you be better, you are kind of saying something when you refuse to use it. When your stubbornness turns to financial loss, you are going to be fired. All he had to do was ask for help. Lord knows he did enough chatting about the girls he could see from his window taking smoke breaks.

There are tons and tons of other automated testing tools out there where people would rather rely on a tool than discipline combined with an automated helper or where they would do the ideal thing and combine the two. Point is, overkill is overkill, but I will borrow once again from Scott Ambler and say that “Barely Good Enough” documentation is required and anyone in IT knows that there is analysis paralysis as well as cowboy coding. We want to be in the middle somewhere but above all else, I believe we (as Clients) want to be the place where the information is and the center of collaboration. The Client organization, if possible, wants to be the “Single Point of Truth” for both documentation and process control. That is knowledge that will be invaluable at some point and it will prevent obfuscation. If a vendor already has something like Bugzilla mastered, you want a login. Do not force change where it will not be helpful, please.

If we miss the aforementioned large chunks of substantive work, we will inevitably see (later rather than sooner) the rise of “issues.” The semantics of calling bugs “issues” have several points of genesis. Many Developers like to call bugs “issues” because after all, they don’t make bugs. Bugs are dirty and involve mistakes. The funny developers call bugs “features” and I guess after 20 years that is still funny. I prefer separating bugs from issues at least in category buckets myself because then the difference between them becomes more obvious and they are handled differently. If math is being executed and addition is inaccurate, we have a bug/issue but if we are not sure if interfacing with an overseas payment processor is possible without their being PCI audited, that is an issue. An issue I actually encountered not too long ago: a development shop wanted to build a RoR font end on top of Ektron. This was one of those delicate issues that was tracked offline.

As with most things, our objective should be to prevent the disease instead of band-aiding the symptoms. To do that, you also need visibility into the overall project health. You do not need granular detail, but if you know that we have 100 units of stuff to fix last week and this week we have 140, things are not getting better. This concept of assigning points to features can be applied to bugs as well. It is all is the estimate and difficulty level. You wind up getting a very visible “velocity” over time where you can see time on the X axis and total open points of the Y axis… you want that line to wind up at zero by a date you have in mind or, more realistically, let it tell you when you will hit zero and adjust the feature/bug (product backlog) accordingly. A tell-tale sign that your vendor is not as familiar with bug tracking or issue tracking is, in my opinion, if their unique identifier (ID) changes or if both entities are tracked in the same manner. The idea of velocity and the multiplicity of velocity is staggering. It does not simply apply to Scrum burndown charts.

Mike Cohn and others divide testing into 4 types: Automated and Manual, Automated, Manual, and Tool-Based. I suppose a footnote belongs here, but as this little tidbit is as much from experience and a variety of media as it is his book (I am not sure which one, sorry).

• Automated and Manual Testing involved prototyping, simulations, functional testing, and user story testing. I personally extend this to service testing (interface testing, touch point testing, etc). For all of these we have information driving acceptance criteria (did it pass?) and the creation of the test (what are we trying to do?) These lead to trackable bugs and potentially, issues. “Fail fast” is made easy by prototyping.
• Automated Testing includes having a Continuous Integration server, Unit tests (this is looking at and optimizing actual code in an XP peer programming model or not and specifically not doing manual testing where you enter orders or send an email to multiple recipients), and Component testing (also done in Tool-driven testing if you have systems within the System configured in a way to allow for it). Your CPU and compiler will tell you a lot. Automatic processes should be set up so that they take place before anything goes live (or even into a sandbox environment). I have seen development shops where if one of these tests failed, a flashing red light went off and in Toyota’s “stop the line” fashion (“Everyone stop developing and look at this!”) people fix what is broken before taking one more step. These lead to trackable bugs and potentially, issues, however these are more likely to be pounced upon immediately because you do not want something icky in the soup, so to speak.
• Manual testing is what we have been calling Unit testing: poking at the GUI, verifying data is validated, things work from a UX/UI perspective, UAT (User Acceptance Testing), and others. UAT is the most important in my opinion. The vendor shows the Client functionality and it either passes or fails. You can have formal acceptance criteria (unscrupulous vendors mandate defined and exact Scope as well as the leverage inherent in highly detailed acceptance criteria). When I am representing a Client who interfaces with vendors, I try to steer clear of hard acceptance criteria and change orders and instead I lean towards reality where things change even if they are correct according to original spec. Clients have had bugs marked as fixed before anyone at the Client even checked or were able to check. This creates haze, and bugs are lost among larger issues, and the excuse is valid, a natural extension of chaos. Vendors have professional responsibility, and this is not my opinion. A company I worked for lost a court case because they did not perform what the court considered part of their responsibility as a solutions provider: proper management of issues. That is why I stopped worked for development shops. Being honest and forthright costs consulting teams money because delivering something measurable that cannot remain the same but must pretend to hold shape will lead to change orders and cries of “OOS! (Out of Scope)” while defining the system in terms of what it has to do at a high level leaves room for change in ways that do not impact behavior. Maintenance contracts bring in a lot of revenue.
• Finally, there is Tool-driven testing. This is load testing, security testing, and hardware testing. This is stuff that your point a tool at and let it crank away and come back with analysis. All projects have a front end that is connected to a back end (not ALL I guess) which is why separating the sites from SAP has always been something I have not understood and so Tool-driven testing is extremely important). Also in this group would be analytics, for SEO, SEM, E-commerce stats, etc).

So I would first recommend enforcing a real, proper, full lifecycle SDLC (Agile if the project is new but if the project is not new, something as close to what exists) and in doing that, most of the testing problems will fall away because Test-Driven Development would catch the silly bugs and if stakeholders change their mind, they will get to weigh the cost of changing their mind before altering something that works.

I would recommend an iterative (every 2 weeks or maybe 3) process where the developers are testing before they say their code is ready and the tasks/bugs that make up the body of work are both large and small but always high in value. That means, in part, developers have to know what they are building against and to have UAT feedback come back to them through a Product Owner (the singular person who approves the list of features and bugs that are coming in the next release and has final Product signoff). I would also mandate a versioning tool like Subversion properly where you do not create a fork until there is a release or spawn a separate effort that will not be merged again down the line. Without proper version control, you can track bugs and issues all day and it will be rendered an exercise in futility if the software is not versioned correctly. There is a marked inability to define what code is shared and what code is not. Some like to track the version of the software where they found the bug. I find that annoying, because we are moving forward, always.

Bugs: There are a billion tracking tools out there. I like any of the automated tools besides Trac (meant for developers, when you look at who winds up using it). The main things we want to capture as a team where vendors have an appropriate level of visibility into the open issues and the ability to assign items (again, keeping the power within the Client instead of the black box of “we understand and you will see it next build”) are present in all of them, by and large. Again, ask a friend. For bugs I think small teams can use Excel but like the workflow and quick views as well as processes that can be enforced by many bug tracking systems.

Identity Field: May not be visible to the user of an automated system, but if possible, I like to show it for purposes of quick reference.

What caused the bug? Evidence, like narratives, screenshots, are important and maybe even critical. If it cannot be reproduced, it should not be presented as a bug unless it cannot be reproduced on another machine but can be reproduced on a singular, or set of, machines. This would be the place for Brower type, version, OS, etc (if needed).

What can we call the bug? A summary of what is wrong.

Who owns it? If it is to make the entry in the tracker more informative, to gather more information, to approve in an approval queue, or to fix, this “owner” may be almost any type of team member. Product Owner will or should give the final approval that it is not active. I say accepted instead of “fixed” because we are going to do regression testing and the owner will be one of the aforementioned depending on if we are doing disaggregation because a bug is really several, holding for re-test, or any number of statuses. Also, the owner should be a group (such as “XYZ Software Development Consultants”) for XYZ to assign to “Jane Jones” who is a developer particularly adept good at fixing that sort of issue.

From here down, the Product Owner / PM / CSM / CSPO assigns the values

What is its Business Impact? From low to high and “showstopper” with numeric values attached to the single decimal point. I maintain that with every bug there is associated Business Value, Difficulty, and User Value. These things are not obvious to the tester but they are to the Product Owner. They combine, via simple math, to give a final value. The “showstopper” assignation is there to really propel the bug’s value into the stratosphere. If low is 1 and high is 3, showstopper is 100. How severely will this impact the business if it is not resolved by go-live?

What is it’s User Impact? Like Business Impact in calculation, but answers the question: is this just annoying, or does it require a disturbingly complex UX?

How hard will it be to fix? This is often a tie-breaker between bugs when creating the next iteration of work and is also potentially an indicator of weaknesses in the team.  I like it when these are estimates or are story points.

Status: Unassigned, assigned, UAT, accepted. You can add or remove as you choose but I like this foundation. When in UAT, it is waiting for Client approval. These should be no bugs that depend on other bugs if possible, and if a bug can be broken into separate bugs, they should be. Open is vague and not required. If it is assigned to someone or a group, it is not closed.

It makes sense to run through bug priorities as time allows to be sure that their values have not changed. If functionality has been cut out, those bugs will have less Impact. However, one bug does not lose value simply because 8 other high value bugs have been found. New functionality should *not* be added until a development team that is constrained by resources can catch up. It is better to have 50 percent of the features complete with 50 percent buggy that 100 percent of the features unusable. Maybe the System cannot be used with 50 percent functionality, but you have value in your pocket there and have paid for something that can be moved to another vendor, another release, or repurposed/sold. Always try to retain rights to and a copy of your source code in your contracts involving custom development. Otherwise, with a new vendor, you are better off starting over. Earned Value will be nil. This is only one of many reasons why “percent complete” is a false indication of anything. Others include that the task/bug changes, has facets revealed that were hidden before, and are as apt to change as anything else.

When a bug is introduced, anyone can introduce it. The default owner should be the Project Manger / Coordinator / Technical Liaison, or whatever the role is called. The Product Owner may also do this but are better off using their time in other ways. This is where the traditional Project Manager can breathe a little sigh of relief amongst all the talk that Agile and Scrum are making the PM role irrelevant. The Project Manager, in a technical setting, should have knowledge of technical systems. They can and should work with the Product Manager to tune value and assign bugs or issues after they are introduced into the System. However, the project manager does not assign to a person. People come and go. They get hit by the proverbial bus. Bugs and tasks are assigned to groups, such as “Development” and then divvied up within that group (hopefully using the same tool) so people are mapped to bugs and there is a face at the standup who will be speaking about it. Also, much as we get a sense of project velocity, we can get personal velocity. I say that and bite my lip, because there is always the “X factor” leaning on everything we do and using pure metrics to ascertain the value of a person is bad, bad, bad, and horrible. This, again, is where the classic project manager could be knowledgeable. You may notice that I am mixing and matching Scrum terms, Agile terms, and more common terms to describe roles. That is not without reason. There is a basic methodology-independent rationale here: keep track of things, limit dependencies, keep visibility and communication high, and stay flexible. Look at what work there is to do and compare it to your deadline instead of trying to shove 10 pounds of tasks into a 5 pound box.

For now, I would propose a bug tracking system with

1. Reported By
2. Date Reported
3. Date Due (optional, more in regard to critical path issues or business commitments made outside planning sessions, etc)
4. Owner (defaulting to the PM/Technical Liaison)
5. Summary/Description
6. Acceptance Criteria
7. Supporting Documentation (documents with screenshots, etc)
8. Site/s
9. Business Value (1-5 or 100 with one decimal place)
10. User Value (1-5 or 100 with one decimal place)
11. Technical Difficulty (1-5 or 100 with one decimal place | high numbers mean more risk).
12. Status
13. Date of Status Change (so if something lies around for a week, for instance, it is obvious).
14. Date Needed (usually driven by a business need or requirement)

I am sometimes a fan of multipliers, like taking the Technical Difficulty field and multiplying it by 1.2 if the team is distributed, contractors, etc. When appropriate. You will know; when you feel like “Yeah, but…” think of multipliers.

I think when the bug is initially entered, the individual reporting it enters the first 7 fields, (maybe not #3) with 8 and 9 and maybe 3 being a Product Owner field, and 10 and being a development field (supplied in an estimate but entered by an informed PM). The initial owner is the PM or Technical Manager (I really just do not like being called a Project Manager because of the connotations and the fact that it does not describe what I do, so know this is a personal preference, please). 11 and 12 are not restricted but can only be moved to “Ready for UAT” by the vendor and “accepted” once tested. This is of course, very much and almost mandated to be customized to your needs.

Best,

Josh

This is a watchdog. Cute, eh?

I don’t really think so either. Looks constipated.

When refactoring a System or system, there is a lot of finger pointing. This is not to say there is a lot of blame, but there is a lot of “oh no, they really did *that*?” and things of that nature. It is quite the perfect place to be in if you have received the contract and are on a time and materials basis.

Fact: I have seen a company spend more than 2 million refactoring what could have been replicated and improved by an installation of WordPress and a slick PHP developer for under 75k.

Fact: I have seen bills from vendors where one developer will bill for 10 hours and when pressed, it turns out that 2 of those hours were actually hours where they were billing for development and for being on a conference call. That same call (the one time I was able to see this proof without looking hard) had 7 vendor team members on the call. 3 spoke.

Fact: I have seen a “botique NYC” firm do Discovery by asking “so, what do you like about your site? what do you do? what would you like your site to do? Okay, thanks for your time!” *smile, wink, handshake* if it is a guy and *smile, shake hands* if it is a woman they are interviewing. The most this interviewer offered? “Let me get back to you on that.” Of course, they did not. They billed an hour explaining the issue to a developer who billed an hour thinking about it and discussing with the Client Manager who billed an hour relaying that we can use RSS feeds to populate a space on the home page. Sure we can. It will be Out of Scope, but we can do it.

Refactoring is like exploring a cave by yourself; it is like a giant fish tale. Even if you did catch Moby Dick, unless you flung him onshore, who would believe you? Should they believe you? What if you were asking $150/hr to tell you the story about catching a fish they were not able to show you?

Weigh the costs of starting over versus refactoring and give the Open Source community and Agile community a chance. I will bet you that 9 times out of 10 a “real” Agile team using Open Source software will come in at less than half of the cost with better quality in a new System than a big 10 company will deliver in a refactoring effort.

LOTS more to say on this. Enough for a book

Thanks,

J

There are lots of places, not excluding my resume.

AJ Ayer stated (as I have mentioned before, yes I know) that if something cannot be proven true or false, it is “nonsensical”. They also say you cannot prove a negative, but they neglect to realize that their statement is that very thing. Ayer did the same. I have not pointed that out yet, but his assertion is by his own definition, nonsense.

What a construct we live in. I guess we have to make order of things and have language and abstractions and whatnot to get along, but some things, like software QA and/or testing is a construct that is not visceral. It is whatever you accept it as.

But still, I see so many test cases and scenarios that cannot have a true or false assigned to them. They get more of a “yeah, that’s pretty much what I think it is supposed to do.”

Agilists would have you believe that testing is dynamic and built into the process of TDD. Sure, it is, partially.

But the System on day 10 is not the System on day 100.

And you don’t know what it is going to look like when it is delivered. So, what can be tested? Only what exists. What exists? What is built. What is built? Either specs or code.

Or expectations.

Beware the vendor that tells you that they can deliver even a moderately sized solution before talking about touchpoints, data migration, business needs, buys you lunch and does it because it gets them time to understand what you need instead of because it gets a steak in your mouth. That steak will be gone and that salesperson will be at another table with another potential Client before you even digest the fillet.

Ask: “How do you know?”

Schedule payments with milestones that correspond to Value. This seems obvious, but it isn’t. Pay for what has worth, not for some arbitrary deadline being reached (time keeps on slippin, slippin…, as the song goes) – for the vendor they just have to worry about not losing you. They dont have to worry about doing a good job. And trust me, many large successful companies are better at stringing Clients along than they are at doing what they say they do for a living.

Thanks,

Josh

There are more than hackers to be aware of.

The worst cases of unscrupulous behavior involve consulting agencies and abuse of trust. They are supposed to be the Domain Expert, so it is very easy for a Client to say “yes, we talked about the dynamic menus… that is a valid line item on the SOW.” In reality, I have seen far too many cases of agencies taking advantage of that trust and coming back with an Out of Scope (OOS) ruling.

Ambiguity is not your friend.

But, over-documentation is not your friend or the agency’s friend. It is the Business Analyst’s friend because it means job security. Long live Big Requirements Up Front (BRUF) documentation, some will say. These are generally waterfall shops. Not always.

You can charge money for BRUF analysis and still leave enough ambiguity that OOS increases cost twofold. Yes, I have seen a project double in cost this way and no it was not a small project. It started as a 1.2 million dollar project and wound up being over 3 million.

Demand to meet your team. Take a look at the office. Stop by “because you were in the area” at 10AM on a Thursday. See who is there. Ask what other projects they have worked on while at X Agency.

And demand iterative, Agile development.

An informed Client is a happy Client, and I would rather develop a relationship that yields trust, referrals, and friends than send some slick sales person in to make a few hundred grand and get rights to use the logo while the lawyers have documentation in place to protect the vendor and hose the Client. Most likely, that slick salesperson will not be called a salesperson and you will never see them again. They will be “on the road” perpetually after you sign and if you do get them on the phone, they are skilled in the art of yessing you to submission and being so so so very sorry will fix it right away, promise.

Be informed. If you do not know what to ask, email me. I do not charge for these conversations. I really give a damn and now have two agencies who I hope to hamstring by offering my insight. They are dirty and I cannot name them, but do me a favor and let me help you before you sign anything. I have that motivation, and I have more private motivations.

Best,

Josh

With old houses, there is always a long laundry list of things that need upkeep. I am in a situation now where I am doing some house-fixing and that list I mentioned reveals more of it’s lovely self all the time.

This past weekend, I had two things I decided last week that I was going to do. I was going to fix the front steps so nobody breaks their legs that I do not want to break their legs and I was going to redo the gutters and replace them totally on the garage.

What I did not know is that the garage roof needed to be replaced. The steps got done, but I wasted money and time as well as life and limb fixing something that was dependant on something else (if you look at it one way) and less important than something else (if you look at it a little differently).

This is why I like FFAs, and why I might just from time to time modify Scrum to incorporate an FFA. Some will argue it is adding complexity. I would counter and say it is removing ambiguity. I can pick my first sprint backlog from something all too similar to Indian Poker (that’s what we called it as kids – it is probably non-PC now?) or I can get as much information as possible about not only the time involved, but the risk and the value as well. I had to fix the steps because Mr. Knucklehead would sue if he fell, but the gutter could have been placed in a larger context that would only be revealed when looking from a 20,000 foot view.

A story point as “how *big* is this item?” is fine, but we really do not want to limit our dimensions of measurement to size.

Thanks,

J

BTW – the aforementioned never happened. I just cannot talk about the real life example due to confidentiality agreements, etc. Besides, I am not feeling well and articulating the real example seems far too tedious at the moment. I just want to go back to bed.