Thursday, July 28, 2016

Ranking rain and risky business events with confidence in strategy and testing

Risk isn't measured easily. It's better viewed as a personal understanding of probability applied to avoiding unpleasant situations. It can also measure positive chances but we'd rather know what the chance of rain is instead of the chance of sunshine. The point of risk management is to find out where risks are and how to mitigate them if possible. Why are we obsessed with measuring it when it's really a useless number?

I am amused by meteorologists who say they measure the probability of rain by saying they measure the area that will get rain as a percentage of the total area and multiply that by their confidence. Nobody really understands what 40% means but that's math. We like percentages for rain and risk because in repeated forecasts, we have something to compare whether it really rains or not for that one time. But the weather guys spend more time than project managers do on that so we'll go with their best guess on risk measurement.

Probability of events

Probability, and therefore risk, starts with measuring outcomes of similar events. To measure anything in a business metric so you can compare results, you need a quantity of a standard unit. Math is funny. When you divide the number of useful past events by the total past events you lose your units of measurement. So you don't have any probability units. There is nothing that assigns an IT project to have 4 RUs (risk units) and another 15 RUs. So probabilities of different kinds of events can't be compared. That's our first problem.

Risk has to be related to a concrete event. Rain forecasts assume a probability of occurrence from a large number of the same types of events and as a stand-in we use similar historical events. A 50% chance of getting heads on a coin toss doesn't mean anything after one coin toss because it's one event. Your only two outcomes are heads and tails. There's no 50% tails. But a history of  500 tosses shows that heads is 50.3%. Now we have some confidence.

Confidence in chance

Confidence is what gets degraded though when we don't have similar events. In projects, we never have the same events so, like the thousands of influences on a storm system, if more of them are about the same, the confidence level of the forecast increases, which increases the chance of rain. Confidence is easier to do when the events are less reality based and can be easily counted. Coin tosses dominate the probability world but even tossing a coin has been shown to be not that easy.

Most business people don't have a backlog of 50 similar sized projects of the same type run by the same project manager with the same budget. The more events with the same influences, the better the confidence value. So confidence is easily eroded making our probability of an event less likely making our calculations less helpful. That's our second problem. We can make an educated guess of how likely the event is based on past events of the same type but the necessary confidence reality check will destroy a risk result.

How priority affects risk

Priority is not risk. Priorities are best assigned to scope units called work packages or use cases that estimate that total value. I like ITIL's breakdown of priority into impact and urgency and adapt it from the incident or trouble ticket to a use case. ITIL puts the value in terms of numbers of people that are affected (impact) and the value perceived (urgency). . For internal projects it might be expressed as a high, medium or low number of employees and high to low level of visibility to executives or high-level managers. For external projects it might be expressed as a high to low market share, and a high to low price point compared to competitive products.

In fact, priority does not influence risk at all. Risk can be multiplied times a priority ranking to show how value is reduced but the end result of a subjective number times another subjective number isn't useful except to compare to each other. Priority is good for ranking order of development of use cases. It's also good for ranking test case execution effort and thoroughness after factoring in development complexity and unfamiliarity of the unit under test.

Project risk

There are two easily confused types of risk in a project. There is project risk which occurs during the project. And there's organizational risk which is taken as a bet when the project is chartered and realized when the value is gained.

PMI defines project risk as "an uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives." But using that definition, since all future events are uncertain, means that all project activities are risks. Even if we declare risk to be the measure of the likelihood of a project failing to meet objectives, we're still in the same boat because any event could conspire to reduce the full obtainment of the objectives.

Project risk bets are taken mostly in design. The bet on the scope to be delivered starts when you spend money towards a design and ends when the product/code is delivered using that design. Strategy and analysis phases can influence design but design commits you to a path. These are all known risks and estimated up front. But there's always a component of unknown risks like developers changing jobs or emergencies but that's what project managers have 'flex time' for.

I have seen risk associated with failure to do adequate analysis called scope definition risk. That's the same baloney as when people call bad requirements gathering down the line, scope creep. This isn't project risk, it's systemic and therefore organizational risk. Check your process maturity and start there with a project constraint. Since you know you don't have good enough requirements management, you should expect some sort of decay around the elicited scope. It's a given, not a risk.

Organizational risk

The estimated value or dollars associated with the project which guides the project manager are broken up into three critical success factors. These three things that make a project succeed are
  • finishing on time
  • coming in on budget
  • delivering total decided scope
The value measurement units that we can use for each of these are standardized into 
  • number of days
  • amount of dollars
  • use cases
The first two can be reduced to similar units of dollars. Days is just a measure of cost of overhead, labor, and other consumed resources. Scope is harder. If you are using good requirements estimation units as recommended in my blogs, you should choose a scope measurement unit that delivers those units of value known as use cases and user stories in the analysis world or work packages in the project management world.

Then you can use a standard conversion of like sized use cases to the approximation of PMI for work packages of up to ten days depending on complexity. So, input from the developers who gauge the difficulty of a use case is critical. Scope estimation is a similar process to test case effort estimation. It might break down to
  • low - 2-4 days
  • medium - 5-7 days
  • high - 8-10 days
The budget component should be constrained at the point at which the value can be assessed before the decision for approval is made. At that point, if the time component is constrained, that creates no flexibility on the scope component and it means that only a certain unknown amount of value can be delivered creating high anxiety for the project manager who hopes that the scope is minimal, the complexity is low, or the developers are wizards. Once the requirements have been analyzed, it may be the that the solution to the project is too big and the scope can't be delivered successfully leading only to a project cancellation and sanity preservation for the enterprise.

If the time component is flexible, then there's still some angst about the outcome but now with some adjustment ability. Using employees over time will still accumulate project cost so knowing the amount of time necessary to deliver a solution may push the expenditures over what the project value is. So where's the risk here if the value is estimated, the time is estimated and the scope determines whether the project is green lighted or not?

The bet on known risks is taken at chartering and cashed in when in production. But unknown risk is in the changing influences on the solution which is a strategy responsibility. A Pokemon Go clone is only good if the market has not produced any other competitors or people feel like they have found enough Bulbasaurs or Meowths.

Strategic constraints subject to influence now become sources of risk. Events expected to happen that influence the planned time for the project or the budget must be listed. How do you judge a probability of occurrence of a one-time future event? You don't. You just put a number on it and rank the items by that. It's all subjective. And the next person puts a different rank on it and then you compromise. Instead of risk, let's call it a proposed ranking of possible scenarios that affect value.

It's all a guess

But because the infinite number of influences can never be known, it's not going to be that useful to collect historical information on what is recorded since the past may not accurately reflect the future. And it takes quite a bit of time to collect, enter, write up those reports, and present. Maybe it's better to just go with your gut when you need to rank risky events. Or see if your arthritis pain is flaring up like it does for weather changes.

Monday, April 25, 2016

The new web with AngularJS 2 & TypeScript - a browser marriage, not a date

The world of web architecture is undergoing its third major overhaul and there’s still more to come. This third version of the web development architecture is centered on the browser as a stand-alone engine so that mobile apps and desktop apps have little differences, developers can write an app and then easily use it on a desktop or mobile device or even embed it in a proprietary mobile app. This is what folks are calling a Single Page Application (SPA).

As web developers, we've discovered the benefits of having static pages, then having our entire web site be pre-processed by the server, and now, since jQuery gave us the confidence to move some of that UX processing to the browser, we’ve been slowly moving more and more to the client. But a client-side web app is a marriage to the browser and not just a date.

Angular's popularity

In the last few years, the client-side processing world has matured, although you may think it’s still in its adolescent phase, but it’s showing enough promise and enthusiasm to garner attention from the big players out there. The buzz is concentrated around Google’s AngularJS web framework which manages a client-side set of views and handles some I/O. Microsoft thought well enough of it partner with Google to provide a much needed improvement for JavaScript called TypeScript. Google dropped development of a similar language and supported TypeScript as a primary language for AngularJS 2, just released in beta as of this January.

Angular also matured through five years of work to find a way to reuse web components like they do in other types of software. But the web is stuck with an amalgam of HTML, CSS, and JavaScript that requires the assistance of the browser to make it all work. And contending with the offline nature of mobile apps put a real wrench into traditional coding. We have to have our own database storage, routing features between pages, and communication with other servers. And we can’t hide behind those protective walls of the secure server.

Google has done a masterful job of keeping a framework both powerful enough to satisfy hungry developers for lots of complexity and customization but making it simple enough to be used by both designers and jQuery level developers. It’s got all the magic of RxJS observables (really? you’re still working on Promises?) but we see patterns to help us code easily with AJAX. AngularJS 1 had this problem of too much high-level architecture and a brick wall that kept them from adding some great features that we now get to have in Angular 2.

The only other major competition to Angular has come out of Facebook’s React framework. It has less buzz and more complexity than most developers need. Unless of course, you’re developing large systems like Facebook. But it looks like it's still morphing into better versions and a few years will give us a better understanding of how to use it.

Working with status quo and my class

In business, there’s a need to keep moving ahead but still use the resources that have been paid for. The frameworks of .NET and Java still rule the enterprise web sites and in order to make Angular play well with these guys, it will take some thoughtful redesign. Remember that these server side frameworks do all the rendering of the web page before the page is sent to the browser. There on the browser is where Angular expects to do its stuff but it makes more sense to do secure data access back on the server and generate a page there for the most part. What we are looking for in a client-side application is to improve that and find the best of both worlds.

The improvements that we are able to get from Angular include the ability to improve the user experience through a faster page rendering. We also make gains when we are able to design a great reusable library of web components that designers just drop in to pages. Those can be excellent advantages if we learn how to trim back the features we've been using on the server and now concentrate on the asynchronous data access and microservices challenges before us.

For the last four months, I’ve been developing a class for my employer, Centriq Training, in AngularJS 2 and TypeScript that I think will meet the need of the business user from the component developer on desktop and mobile to the designer who thinks about the future of web components possibly using Google’s Angular Material. It's been the most difficult course I've written.

It's been a challenge since minimal documentation was available to start, other published material was poor except from the Angular developer community (God love you Pascal Precht and Victor Savkin), and documentation continues to be updated by the user community. The AngularJS 2 API docs have a lot of "WHAT IT DOES - Not yet documented"in them. But, hey it's still beta. For the most part, it's midway between the massive headaches of the patchwork packages without a framework I see with JavaScript solutions and the tried and true .NET frameworks.

I'm always seeing improvements and industry support which indicates that TypeScript/AngularJS 2 is going to be a leader for years to come. The editors I use are a delight. For free use and my class, it's Microsoft Visual Studio Code, which has nothing to do with the Visual Studio editors for C# and other languages. (Do they know they are following in the footsteps of confusing Java and JavaScript?). That and JetBrains' WebStorm are the best tools available so far.

If the transition to responsive design and mobile apps didn't overwhelm you and you want to see how the next wave is going to improve things, it's definitely worth a look to look at these mature products that will continue to have an effect on the web architecture for the next five years easily. Hope to see you in class!

Tuesday, January 5, 2016

Assertions & assumptions, eels & heels - Clear terms create understanding in analysis

There's several terms that cause confusion in analysis and sometimes they come in pairs. The two are preconditions / post-conditions and assertions / assumptions.

It's not that people get them mixed up, it 's just that they use them however they like. It's so much better when you know what you are saying and know why you are using the term appropriately. A clear term used properly is the beginning of analysis understanding.

It's not that I blame any particular reason for not using terms well because I know I had no clue when I was suppose to write up a project document and the people I was learning from had bad habits. It's like when my wife regretting doing something said she "felt like an eel." It's an obvious thing if you know the real use of the term but can cause confusion in those that don't have that experience.

Preconditions prevent functionality

In a use case, there is a particular section of preconditions which never is fully explained and ends up being a convenient way to start a use case from the middle of the scenario. My favorite example of this is when a use case requires the credentials of a user to be checked as part of the process. A log-on process is always part of a secure use case. It should be modeled as a part of a goal-driven use case.

Many people shortcut writing the full scenario by avoiding the repetitious log-in tasks and declaring that the user must be logged in as their precondition. So if logging on has changed the state of the system to a different state, that use case must be a complete use case that leads to value for that changed state. The log-in, no matter how many people log in, will not provide the business any value whatsoever. It's not a separate value-driven use case. Ever.

The precondition is a state of the system that must be true in order for the use case to progress to the first step that is unique to this use case. In the classic ATM use case example, you are prevented from doing a Withdraw Cash use case when the machine has no money and the menu option for withdrawing cash is disabled. That means that the precondition for the Withdraw Cash use case is that the ATM can pass the rule of allowing a user to withdraw up to their maximum daily limit or some other rule. The state was changed by a previous Withdraw Cash use case which did have value.

In a business use case where the user first drives to the bank's outside ATM to get cash, the precondition has to change some. The scope of the business system must include the full bank property and building. The system precondition is that of the machine having enough cash but business way to prevent a person from using the ATM is to put a traffic cone in the ATM lane or turn the system off. It's anything a manager would do that doesn't involve the software itself.

Post-conditions repeat important tasks

Use case post-conditions are usually defined as important things that need to be affirmed at the end of the use case tasks. That usually means repeating the important changes noted in the use case narrative. For instance, in the classic ATM example, a post-condition will be to make sure that the bank got the message of a withdrawal transaction at the end. But it doesn't have to be a state change. In fact, the state of the machine should return back to the way it was before the use case started if we are to follow the rule of being able to run a use case multiple times.

The post-condition of the bank transaction is that a message was confirmed to be sent to the bank by some means. In the design stage, this could be a callback function to the ATM or a log provided by the bank. Either way, it should be a task that could be audited.

Assertions are conditions too

Assertions are more of a programmatic style of pre or post-condition when the condition involves only that code. You assert that inputs matched your data rules, a technical precondition. You assert that outputs match your data rules or the state of something changes, a technical post-condition. The code for assertions is removed when deployed.

Assumptions occur after analysis

Assumptions however are not preconditions. You don't get to assume that your users are logged in. They are important decisions taken at design time when we need to guess and take a bet on the chances that something will occur. You assume that a health care system you manage will be affected by a possible repeal or replacement of ObamaCare.

You can understand what your stakeholders want in a sign-up site for your insurance and you know that they want something that follows and takes advantage of the current laws. But there's an uncertainty that is measured through a risk assessment process of whether or not the bill will pass. The project manager will be the one to assess the risk and make that bet on the value that could be gained or lost.

If the choice to take the risk is a good one, then the design team starts working on the system and while they are designing screens and systems, the assumption must be made that there will be a replacement for ObamaCare. Not all the risks that you assume in your design will happen but the choices you make may allow for you to reduce your time to market increasing the value of the system on the ones that do pan out.

Create understanding through clear terms

Terms, although deposited squarely in your beloved template, do not mean that they are correct. The best way to gain some understanding is to start questioning what the value of each piece of information is in your template. Corroborate that with the other team members. Update it, move it, refactor it, or delete it. Make it useful. Add an appendix if you have to. Then it will start being more understandable.

Thursday, December 31, 2015

Friend or foe robot? Designing automated processes for business

Programmers are guys who write your business processes with a kind of invisible ink they call code. The better you tell them what your processes are, the better business results you will have. They don't really model your world because they have no clue how the business works.

Programmers will come up with a well-engineered version of the reality they perceive if left alone and that will have to be the way you run your business if you don't tell them how the business works. It will likely more resemble a massive robot rather than a enabling friend.

As a programming instructor, I talk about the declaration and reuse of a set of statements that become methods (or functions or procedures).

As a business instructor, I teach the same thing concerning recognizing a useful process and promoting the larger scale use of it into the business. As your process maturity level grows, the process expands from your own use, to people around you, to even more people until it's a company-wide standard.

Architecture

Those same maturity steps are used to develop large scale architectures that provide guidance to the necessary design of the infrastructure that has implemented it. In fact, it's the principles of good design that produce a workable architecture. Sometimes business doesn't know which architecture to choose or isn't able to strategically point the direction and then takes the low road of design by infrastructure. This is the choice to buy instead of build and results are good as long as you stay compatible with the other components that are added on. Again what you end up with is a well-engineered solution without regard to your specific business needs.

The business processes existing within a coordinated automated system or an infrastructure are essentially the executable programs. They have been structured to achieve a specific objective. They take inputs and turn them into outputs. They have a specific trigger. They are layered into automated roles and responsibilities to work well when they have to be maintained. Just as if it were an employee, you can fire an architecture layer and hire another version of that layer that fits the bill when managing a cohesive set of responsibilities in a business.

As far as I know there's not as much business writing going on for how to design a job role with few dependencies to other job roles but one of the common axioms of being promoted in business is that you must make yourself replaceable or else you'll never get out of your job. That's the same kind of thinking as when programmers say they must make their programming units reusable or maintenance will become more of a headache.

The process

If processes equal computer programs then they must have similar features. They can be broken down into smaller processes. They are either ongoing processes or processes that have well defined starts and stops. Processes can update policies, standards, guidelines, activities, other processes, procedures and work instructions if needed just like computer code can generate other code, update rules, and modify data that change how the program operates. A program is made up of activities, procedures, and work instructions or as the programmers know it, the class, the methods, and the program statements.

Metrics for a process are built in from the start and can be injected into computer code or built in to the abstract base of the code. In business, the best place to think about your metrics for success is during the planning stage so you can always build with them in mind or else you'll have trouble retrofitting them later. Roles of who should be involved in the process are important. In code, the types of relationships that you maintain with other code is important and successful relationships are spelled out in recipe books called design patterns. I admire Peter Coad who tried to assign roles to classes and discover some reusable patterns for interactivity and not just static recipes.

Process improvements are always a part of all processes and can be found in wrap-up sessions or project post mortems. In code we get a closed feedback loop from the folks who are using the programs who give us reason to enhance the program and get more financing for the next maintenance project. Feedback comes in the form of new or improved features and it gets added to the system as the value becomes known.

Processes should also be well defined in understandable text just like we always do to our fellow programmers when recommending comments in their code. And just like the norm in programming, most documentation happens after the fact because people don't have enough time to document the program until it has stopped changing at the end of the development cycle.

Process owners are the people who understand the process and can help educate others on how to use the process. I help ITIL students who think process owners are not in charge of implementing the process. This always gets me on my soapbox. An implementation of a process, e.g. an ITIL key process, is not going to happen because you read the book. It must be digested, customized by deleting the right parts, and supplemented with all of the current business structure in order to be understood. Then the process activities are noted and people check them off as they need to when they need to encouraged by success and trimmed down by reality.

In programming, it would be the project sponsor who got the ball rolling for the new software and would own the software when complete. They also get new funding when the project is a success and get project funding reductions when the process is too cumbersome.

How and when the process is used is a matter of policy and the ways that you can use these process steps have limits. Just like a computer program, the steps can be run for certain types of tasks and shouldn't be run for others. You don't close the books of an accounting process except for once a month. You don't ship more inventory than you have in stock. Process objectives are probably determined by what planted the seed in the ground for using this process in the first place. In a software project, the business objectives drive the funding and usually can be found in a business case document or a sponsor's mind.

I was reminded of the input and output nature of a process when looking at the method declaration and saw that it defined a general form of a resource just like all the other types of resources.  But until functional programming came along to supplement object oriented programming, we never had a way to send the process information from one place to another internally even though the values of any data could be sent to and fro.

Process testing

Software testing is a way of thinking about your code from the norm or from the original business requirements. This validation is a quality aspect of coding. Test driven design drives home the point that the test is a way of thinking about how your code should be called and used before the implementation is written. ITIL states that
"Even before starting, it is important to think about what the process outcomes should look like." (Service Design, p. 44) 
We also work with requirements in a hierarchical way so that the lower level requirements of the code can roll up to the next level of activity and eventually be mapped to the business goals that drove the project. Then when the system is complete, we have a measurable way to compare what was originally planned and implement improvements if necessary.

Process enablers

The enablers of a process are combined assets of the resources and the capabilities of the business. These are the raw materials and the smarts of the folks that are getting the job done. On the computer programming side are the programming language capabilities and the hardware and software's raw power to get a calculation performed or a sequence of code executed. We measure performance here in FLOPS (floating point operations per second) and computers are moving through the petaflop (1,000,000,000,000,000) ranges now.

Business processes depend on the business assets just like code depends on the infrastructure it runs on. Unfortunately, business is both enabled and limited by humans and computers both enable and constrain business.

Get in front and drive

Processes are not much different whether you do them manually or if you have a robot do them for you. The programmer acts as a plumber in a business process. They know the mechanics and apply the right torque to the right nuts and bolts to hold the system together. The business analyst is going to map out the system so that it works for the business the best.

Sometimes the programmer has no choice but to plan it out and do the best they can. But the business should always get involved at the first to direct the code so that is best represents the business. That's always the best strategy to take for any new project. Don't let the programmer be a back seat driver and transform your software project into something you didn't expect.

Monday, December 21, 2015

Building your dream home - knowing web site roles and skill sets


As a teacher I'm interested in getting the right information to the right student. A major part of my training is web site building and students often want to know what skill sets to learn for their job or career. Building a house is one of my go-to metaphors I use when talking about developing a web site. Getting a home built from the ground up takes skills from
  • a general contractor to get all the people collaborating, 
  • an architect / designer to figure out how it should be lived in, and 
  • the carpenters, plumbers, electricians, and other specialized contractors to build it.
You can separate the skill sets of building a web site into those same basic categories or roles:
  • admin people to set, build, and deploy the code
  • GUI / UX designers to understand the work flow and usability and
  • the developers and database people who make it work.
These roles of the web admin, designer, and developer have been implicit in many job titles and much training can be fuzzy about who should be learning what for the best results. Here's my simple guide to what skills each role could need in a prioritized list:
  • Web admin - OS, network, server configuration, server-side language, JavaScript, architecture, HTML, CSS, graphic arts
  • Web designer - graphic arts, CSS, HTML, JavaScript, server-side language, OS, network
  • Web developer - server-side language, JavaScript, database, architecture, OS, network, HTML, CSS, graphic arts
My classes at Centriq (including some I no longer teach) and the roles that they target in groups by primary role would then look like:

Admin
  • WD- ??? - JavaScript tooling - admin, developer, designer
Designer
Developer
  • xxx - any Java, C#, or php class - developer, admin
  • JV-394 - Intro to XML - - developer, admin
  • WD- 405 - JavaScript - developer, admin
  • WD- 520 - JavaScript Powered Web Apps - developer, admin, designer
  • WD- ??? - TypeScript - developer, admin
  • WD- ??? - Angular 2 - developer, designer
  • SOA-102 - SOA Intro - developer, architect
The JavaScript Powered Web Apps doesn't get you hardly any design because it's about setting up a web site using nothing but JavaScript. That means that the web site isn't much to look at but it's very cool under the covers. The classes that don't have numbers are because they are new. The JavaScript Tooling class is a two day class highlighting the admin skills for JavaScript based web sites and was taught along with the JavaScript Powered Web Apps but is now offered separately. TypeScript and Angular 2 will be offered next year and are completely new classes.

I hope that you are better able to guide your educational path towards a team of skills so you can build your own personal dream home with some of these role explanations. 

Sunday, December 13, 2015

Don't be a LeBron and write user stories for you. Create team value with these examples.

Lebron James by basketlol
I'm still not happy with Agile user stories. The user story should set a goal for the team. Most perspectives of story writing I see follow the LeBron James school of thought. The typical user story I read finds value in winning for the individual player and then the projects follow those rules running into conflicts. I think it's time to do some coaching examples from stories I found on the internet.

The easy expected format

The traditional user story format:
As a (role) I want (something) so that (benefit)
is supposed to benefit the person/business paying for the work. Or at least that's what I want if I'm in charge. You don't want to watch the project goals slip away and then everybody and their dog starts wanting something different. Without a guiding set of project value propositions, the user story will look like
As a <stakeholder> I want <something for me> so that <several excuses>.
Just making an excuse for a personal need does not make a user story a requirement nor makes it easy for a developer to code it. When it's in any kind of formatted statement, the analyst can put it neatly into a document and make it passable as a project document. It's now user stories. Nobody questions it because there are no well understood rules about a good user story.

So stop already. Here's my rules (I get to make the rules if I'm paying for it):
  • The role/stakeholder triggers the activity. It's like a security group description instead of a real type of person at this point. Make it broad.
  • The something is for the business. Make it the focus.
  • The benefit is for the business. Make it have value. No excuses.
  • Use testable functional requirement writing. Any kind of limitation of data or process is a rule.

The hard part

Let's apply this several different ways to sets of requirements I found. In my style of writing requirements, the business rules are extracted out and placed under the requirement (they are given an ID if reusable and placed in another document). The information about the data entities are extracted out and placed in a data dictionary with the business details. The design elements are noted. And any project information is noted as well for inclusion in the project plans. Only the rules stay with the requirements while the rest get sorted and filed away in their own documents.

Desktop backup app

  • As a user, I can backup my entire hard drive.
  • As a power user, I can specify files or folders to backup based on file size, date created and date modified.
  • As a user, I can indicate folders not to backup so that my backup drive isn't filled up with things I don't need saved.
It's interesting to me that this first choice extracted from my Google search didn't bother with the benefit part. So here's my take on them collapsed into one story:
  • As a user, I want to backup my hard drive so I can restore files.
    • RULE - select files by size, date created, data modified, user choice.
    • RULE - select folders by size, date created, data modified
    • DATA File: name, size in Kb, date created, date modified
    • DESIGN - option to select an entire disk backup is the default?
The distinction between the two roles fades away as the trigger is the same for the same result. The ability to use rule-based choices for file selection is what the user story author thinks is important. But the importance might come if there is a functional difference. The distinction between the user and power user will appear as design personas for testing.

Most of the meat of these requirements is in the rules which corresponds to my experience of seeing a document fluff up by including the rules as variations of requirements. It's just bologna.

Agile project management app

Here's another example of four related user stories with other information included from the three other stories that were deemed too broad (vague) or too detailed (mostly data info):
  • A team member can view the iteration's stories and their status with main fields.
  • A team member can view the current burndown chart on the status page, and can click it for a larger view.
  • A team member can view or hide the tasks under the stories.
  • A team member can edit a task from the iteration status page.
This one was interesting to me because the template for writing a user story looked very promising and included the goal of expressing business value. I just didn't see it in the stories. Here's my version:
  • As a team member, I want to view project user stories to be aware of project scope.
    • RULE - select stories by iteration
    • DATA - User Story: status, tasks, main fields(?), rank, name, size, package, owner
    • DESIGN - tasks are able to be hidden and shown under story
  • As a team member, I want to view project status to be aware of project management metrics.
    • DATA User Story: is in scope, hours estimated, hours worked
    • DESIGN - project status is best viewed as a burndown chart
    • DESIGN - the burndown chart should be able to be viewed larger
  • As an analyst, I want to manage user story tasks so that user stories have details.
    • DESIGN - CRUD should start from the iteration status page
I know there are four basic operations on entities which occur. When they all occur together, I find it useful to use a higher level requirement using the word 'manage.' The two operations mentioned in the original versions, edit and view, would be paired with create and delete in a full set of user stories. Data base people know these basic CRUD functions. The entity discovered in the requirements is just the User Story. The project status is a report of all in scope project user stories.

Credit card payment

Another story with additional details from the same Google search result above really did use some value so here's what it looks like before:
  • As a purchaser on the website, I want the ability to pay with a credit card so that I may immediately confirm my purchase.
  • Acceptance criteria
    • accept Discover, Visa, MC
    • Validate CC# when entered
    • Validate expiration data and CVV
    • Validate billing address
    • Generate success and failure messages after processing
  • Definition of Done
    • passes all regression tests
    • passes testing per acceptance items
    • approved by UI team
    • able to show feature in company demo
  • mockup.png
and after using real world documentation:
  • As a customer, I want to purchase a product with a credit card so that transactions are convenient.
    • RULE - credit cards must pass basic local validation before submitting to credit card processor
      • credit card type - Discover, Visa and MC
      • number - passes Luhn algorithm
      • expiration date - after or equal to date of transaction
    • RULE - credit cards submitted to credit card processor must validate with the following information (or create separate DD item)
      • credit card number
      • expiration date
      • card security code
      • billing address
    • RULE - credit card validation should be done within 2 seconds
    • DATA Credit card:  type, number, card security code (not stored), expiration date
    • DATA Message: body, time/date, ID
    • PROJECT Testing, exit criteria:  All regression tests must pass.
    • PROJECT Testing, exit criteria:  Entire UI team approves screen forms.
    • PROJECT Testing, user acceptance: prepare mock data for company demo
    • PROJECT - Project plan, stakeholders: Credit card processor, customer
    • DESIGN - suggested screen layout of entry form - mockup.png
    • DESIGN - self-service customer purchases are best made on a web site
I really don't know why I need to confirm my own transaction since I can't confirm with anything. The confirmations are the validations which should be made quickly. The validations are really in two phases since it's a system dependent on a credit card processor.

Summary of value driven analysis

I believe that people don't do requirements well. It's why user stories were advanced as a replacement for bad requirements. In some ways I agree with Cowan+'s throwing the baby out with the bathwater statement, "User stories are not requirements. They were meant to replace requirements, which suck." But I think that they just help do a better job at user needs elicitation. And then the rest of the analysis should be about writing the business value user stories/use cases.

By following a format of zeroing in on the functional requirement and extracting out all the distracting and fluffing-up text into their own documents, I believe it's much easier to create usable requirements. The thing that drives the requirements the best is value. But it's value to the business, not value to the individual stakeholder. Do it for the team. Don't be LeBron.

Past related blogs


Wednesday, November 4, 2015

Re-inventing usable requirements: Value-driven projects & the failure of the Agile user story

Hubble Helps Find Smallest Known Galaxy Containing a Supermassive Black Hole
I'm fascinated by the attraction of the Agile user story with requirements writers and the effort to make it be a final usable requirement. Stakeholders format their needs from their view using the simplistic Agile user story. But they shouldn't. That list of stories then becomes the requirements document or backlog with little analysis. It can reel in any amount of confusing scope easily much like a black hole will attract anything it gets close to.

I wrote about rewriting user stories into business' goal targeted requirements in my last blog and my best words to describe it is as a value-driven approach. After writing that I found that Elizabeth Keogh (@lunivore) suggested that business value is more important than the user role back in 2008. But I want to go deeper. I find that the detail level of the user story is unusable as a coder except to start making informed guesses.

Project value

Needs elicitation is the common starting point of a project. This is normal. Needs are selfish. But needs can't be met until everyone decides what the business goal is that the needs address. The goal should be to solve a business problem. The agreement on the problem statement becomes the starting point for gathering focused needs.

Once there is a problem statement, the needs can be framed in that context instead of the individual project stakeholder or customer. I don't think the stakeholder is going to give you any amount of money to write your code so why tailor the project to each one of them? It's the business that gains the value; it's the business that pays the bills; it's the business that should be the context of the requirements.

User story versions

Scott Ambler, a prolific Agile writer and process thinker, outlines the user story on his Agile Modeling site:
  • pre-2008: user story begins as an informal simple "I want a ..." kind of statement
  • 2008+: Mike Cohn adds the party benefiting from the value In User Stories Applied with the format of "As a (role) I want (something) so that (benefit)."
Scott has a list of user stories on his site in the informal style that include:
  • Students can purchase monthly parking passes online.
  • Parking passes can be paid via credit cards.
  • Parking passes can be paid via PayPal.
The Mike Cohn user story of the first bullet point above according to Scott would be:
As a Student I want to purchase a parking pass so that I can drive to school.
The Elizabeth Keogh user story of the same story would probably look like
In order to drive to school, as a Student, I want to purchase a parking pass.
Both of those examples have the Student getting the value. If I'm the starving student, I want to park free. Did you people ask me? None of those are real benefits. After I get done changing this need into a value-driven requirement it will look completely different:
The school sells permits to park vehicles on school property.
You'll see the benefit as a large scope requirement that traces down (is a parent item) to this requirement. The user story is a needs elicitation tool but with a process flaw. The user stories are passed on the the programmer who think they have structure. The reductionist user story rearranges the words of the "requirements" you find in an Excel spreadsheets and passes them on to development.

Needs vs requirements

A need is a statement of any scope granularity, any priority, with or without a responsible party, and either functional or not. It could even be a design as envisioned by the stakeholder trying to grasp how to convey what they think will get the job done. Needs have so many shapes and forms that they can't be processed easily. They have no structure which is why "requirements" meetings last so long. They are really needs elicitation brainstorming sessions.

Needs have to be rewritten into organized requirements. A good requirement has structure. That structure is testable. A good set of requirements is complete. That completeness is validated by a model and the stakeholders. Structure and models take training and time to do well. Stakeholders don't have that time. Analysts do.

The biggest problem for my students in my Business Analysis class seems to be stopping at a good enough stage where the needs are all lined up neatly with enough words so it looks passable. The critical thinking skills should kick in to test the requirements but the tests are not well understood about what the goal is for a good requirement. Programmers don't communicate and use their tool-driven BDD/TDD/XDD style processes to wrangle the statements into some code.

Value-driven requirements

My value-driven approach for the first parking pass requirement would be much more detailed and focused on the school that is paying for the project. A goal accomplishes business value in a functional requirement statement and can be rolled up to a goal group. A goal group expresses larger scoped business values. For the goal, rules express how the functional requirement is to be executed.
  • Goal group: The school offsets direct costs for parking.
    • Goal: The school sells permission to park vehicles on school property.
      • RULE: parking permissions are valid in one month increments
      • RULE: permissions are only offered online
      • RULE: permissions can be paid for with credit cards (Visa, MasterCard, AmEx) or PayPal.
  • Goal group: The school provides a secure environment.
    • Goal: The school controls vehicular access to school property.
      • RULE: Drivers access school parking lots through entrances requiring permission.
  • Design recommendation: parking passes should be used as permission evidence.
The Student of the user story is a valuable piece of requirements information but not for the requirements statements. It should become a persona as long as descriptive details are added to make them more real. Personas should be used as a design step in the project and for testing but not for requirements. You'll also need an Instructor or Employee persona.

A parking pass is a permission mechanism that can be replaced with another solution and not affect the requirements. That makes it a design choice and unless there is a constraint on the project for doing it, it is not worded in the requirements statements. It should be captured as a stakeholder idea for a solution in a category of design recommendations.

My goal follows a similar structure as Alistair Cockburn's goal driven use case except for adding the rules directly into that scenario if the rules are not reusable in other use cases. Many goals should be able to be found that roll up to a goal group. And goal groups can be drilled down into to find other goals. Business value becomes more strategic as you roll up your goals.

It's the focus on solving our own needs as we see them instead of creating value out of solving a business problem that has us creating confusion in requirements. Encourage the stakeholders to start thinking as a team from the business viewpoint and find the value that is in your project.