Smelser.NET

Whether your following the SCRUM process or not, at some point you've been asked to "estimate" your work. Not surprisingly, the answer to this question often comes in the form of days, weeks, or months. If your providing a Rough Order of Magnitude (ROM) (a.k.a. ball park estimate) for some proposal this may be fine, although this kind of estimation can get you in trouble if you don't add that all-important padding. At this point, your probably saying... Duhhh!... and you surely recognize why. We add padding because we've not taken the time to think about the details.

Unfortunately, it's all too easy to follow this same pattern in Sprint Planning. I can't count the number of times I've witnessed Backlog estimation with the same cavalier days/week estimation approach. To be fair, I've been guilty of it myself and usually pay the price of over-committing myself because I skipping the details. According to SCRUM process tenets, the second half of the Sprint Planning session is dedicated to breaking down "how" we'll deliver the requirements identified in each Product Backlog Item. This is the time for us to think about the detailed tasks that must be accomplished as part of any piece of work. Look around, and you'll find no shortage of guidance on how to structure these but lets see what Ken Schwaber has to say.

While designing, the Team identifies tasks. These tasks are the detailed pieces of work needed to convert the Product Backlog into working software. Tasks should have decomposed so they can be done in less than one day.
- Scrum.org (http://www.scrum.org/scrumguides/)

Notice there is no specific number mentioned, although it's implied we should break tasks into sizes no larger than one productive day (whatever that is). This is really clever, because; if achieved; team members can easily assess real progress from one day to the next and be able to both report and observe this progress in the Daily Scrum meetings. If we combine the desire to avoid over-committal with making progress more observable for the team, this seems like a no brainer... Then why do we keep skipping the all-to-critical break-down step? Assuming it's not plain old laziness, maybe we just need some ideas on how we can break down tasking. For me, I often use my definition of "Done" to start guiding my detailed task list.

• Author Code - Try separating your target layers into separate tasks (Ex. Domain Repository, Dal, etc.). This isn't meant to represent a list of classes but it can represent layers of discreet behaviors/functionality. If your developing visual interfaces this could reflect components, user controls, or other visualizations
• Author Tests - As a compliment to authoring the code, create separate tasks for testing each developed layer or component. The previous tasks allow you to report on implementation of required functionality while these tasks allow you to report on the confidence with respect to completeness, reliability, etc...
• Integration - These tasks identify work often required for larger products and may represent dependencies you have on other resources such as graphic arts, localization teams, etc. Additionally, you may also want to set aside tasks to integrate new products and/or components into your build process, source control, and/or CI tool-sets
• Reviews - This reflects interactions you inevitably need to have with other people, and can serve as a nice reminder that you need to coordinate/review material you've authored/updated. This could include things like peer reviews with other developers, component introduction with the test team, etc...
• Deployment - Set aside tasks specifically targeted to implement/update those things you need to deploy your product. This may include installers, configuration profiles, monitoring resources, data stores, etc...
• Documentation - This reflects tasks related to documenting what you are going to do or have already done. This could range from release notes, code documentation, test cases, user documentation, etc... 
• Demo/Review - Don't forget to set aside a task to prepare product scenarios for the Sprint Review/Demo

This isn't meant to be a complete list and I'm sure you can think of additional items. If you think about it, this really isn't hard and making a quick bullet list of items such as I've done above doesn't take much time. Conducting exercises like this may help you realize that your shoot-from-the-hip estimation may not be enough to produce a "complete" product. As an added bonus, this kind of detail in your estimate can really help facilitate discussions with those that complain... "What do you mean that takes two weeks?". As with most things, the devil is in the details, so don't just assume you'll remember them, break them down...

Tags: processes

In my last post SCRUM-tastic Tuesday - Estimation guesswork, I proposed a simple approach to estimating work and managing expectations. After the post I got a few emails about the value of the Delphi Estimation method. Specifically, the writers mentioned the anonymous collection of estimates as the only real way to see how close or how far apart people see the size of a piece of work. Here is a basic summary of how it works:

• An assigning manager approaches two or more developers separately and describes a single unit of work
• Each developer estimates the work as they understand it and submits their estimates anonymously to the manager. Neither developer knows about the other and the manager does not know which estimate came from which developer
• The manager reviews the estimates. If the estimates are more than 15-20% apart the manager calls a meeting to discuss the difference between the estimates
• After the meeting, the developers re-estimate
• This process repeats until the estimates are within threshold (15-20% in this case)

This sounds complicated but it does work. This forces people to explain why they saw things so differently, often leading to the discovery of assumptions and/or risks observed by one that was not considered by the other. This approach also addresses the issue of peer pressure. We have all seen it... Put the team in a room and ask them for an estimate and often you will only hear from a few people. Unless those few people are doing all the work, you may have estimates that don't reflect what the actual assignee can commit to. This kind of communication can go a long way to ensuring your estimates reflect real concerns. 

In a Scrum environment, the problem is time. The aforementioned process takes a lot of time and orchestration, which Scrum shops don't have. There is however another process that strives to capture the value of the Delphi method while prescribing a process that is fairly lean with respect to artifacts and time. Its called Planning Poker.

For me, this process gets to the heart of the matter, which is forcing full participation. The process is simple:

• Bring all the devs together. Just like Delphi, explain each unit of work and ask the developers to estimate using numbers provided on a set of cards
• Everyone shows their estimate card at the same time allowing everyone to see each others cards
• The facilitator will be able to any see big differences immediately and ask each person to explain the assumptions and/or concerns reflected in their estimate
• After a round of discussion, the team estimates again, repeating if needed

This process can go very quickly and provides all the same value as the Delphi method, although the artifacts created in this process often have a much lower fidelity. Strictly speaking, the cards are not critical... You could just as easily use yellow stickies, as long as the value choices are the same. Personally, I like using one of the many IPhone or Windows Mobile apps for this (Ex. Space Flight Orange).

While the previous example focused on dev shops this process is a great way for team managers and product owners to do rough estimation ahead of the planning sessions. This allows each party to get a sense of which pieces of work are larger or smaller and can guide selection of priorities. In this case, they are not trying to nail-down detailed estimates; instead; they are trying to define a rough approximation (often in days). This is also known as a Rough Order of Magnitude (ROM) estimate or a ball-park estimate.

Technically speaking, there is a little more to the process so feel free to read up on it. Whatever you decide to do, just remember, the most important part of getting reliable estimates from your team is getting people to communicate... chickens and pigs.

Tags: processes

Whether your using Scrum or some other Agile process, at some point you will be asked to Estimate your work. So what is that... as if you didn't already know: 

The ability to accurately estimate the time and/or cost taken for a project to come in to its successful conclusion.
- Wikipedia (http://en.wikipedia.org/wiki/Estimation_in_software_engineering)

The truth is; unless you are building templated software like toys on an assembly line; good software estimation is generally some combination of experienced guesswork, historical evidence, dumb luck, and black magic... If you are using processes that require higher fidelity artefact's like CMMI, SW-CMM, etc... then you may be familiar with estimation practices like COCOMO, Delphi or others. If you are working on very large projects, or you need to do long-range estimation, these techniques can make a lot of sense.

In Scrum, you have roughly one working day for the business to articulate its needs and priorities for the next iteration. During this same time the Team has to figure out what they will commit to delivering, how they might do it, who in the team will do it, and how long it might take. With so little time, traditional techniques just aren't practical so the estimation priorities need to be shaped accordingly. A key practice in any project is proper management and communication of expectations, risks, etc... So with that in mind, here are the tenets of our estimation process:

• The artefact should be quick and easy to produce...  Keep it simple and reuse your tracking system if possible, letting the assigned task list represent your teams estimate (Ex. TFS, Microsoft Scrum, VersionOne, etc...). It could be as simple as a spreadsheet or even an email to all concerned
• Communicate where the team has a lack of confidence in their estimates and why. Managers can use this to get a sense of how much contingency;if any; they need to add to an estimate to ensure customers are not too disappointed if things go the wrong way
• Communicate what risks, resource shortfalls, or impediments the team is concerned about. This would include things that could place the teams ability to deliver commitments in jeopardy. Generally, these are items that need to be addressed by Product Owners or the Scrum Master
• Communicate any assumptions the team is relying on as the basis of their estimates. This would include things that; if not true; could dramatically change the estimates

This may sound like a lot but this can be done very easily... Here's a sample of a spreadsheet that demonstrates each area:

As you can see, this would take very little effort, allowing the team to spend more time talking about more important details. On the other hand, this clearly communicates the points that shape expectations.

Even if you get the estimates correct, there is still one element that can cause you to estimate incorrectly and technically speaking this should be done before you estimate. What is it?.. Defining your teams Capacity. Essentially, we need to make sure we don't over-commit the team or any one member of the team. This process is pretty straightforward and does not require much more then a white-board discussion. Here are some things that should guide this calculation:

• Will any member of the team be taking a vacation or any other planned time away from the team?
• Are there any company holidays?
• What is the team's productivity rate? This is the number of hours per day each team member is expected to be making progress towards the completion of committed tasks. This tries to achnowledge time spent on the phone, answering emails, attending meetings, training, lunch, etc... No estimate should extend beyond this number

Hopefully these tips will help make your estimates a little more successful.

Tags: processes

When you are working as part of a development team, one thing that can get you in trouble making code submissions before the code is ready.  Unfortunetaly, assessing whether or not your code is "ready" is a subjective process, but there is something you can to avoid problems.  In this case, you need to define the teams agreed "Code Promotion Path"...  That is to say...  What has to happen  before code may be checked in.  Every environment is different, so you need to define a path that makes sense for your team.  Whatever the team decides, it is a good idea to write it down, and publish it somewhere all stakeholders have access to.  Here is a simple example that may help give you some ideas: 

The decision to accept changes to the source library is informed by a review of key elements by key stakeholders

	Security-focused review to identify product vulnerability and assess risk to the product owners/sponsors. Manual inspection, Architectural review, Static Code analysis review, and other testing can be used to assist this process
	Code Peer Reviews to validate requirements, and compliance with Project standards & specification
	Architect review to assess conformance to architectural tenets, and adherence to the original product design

Tags: security, processes

When you are working in a large development team it can often be a challenge to get everyone to agree on simple things... When it comes to testing there are a lot of factors that drive whether or not the total team is ready.  This is something that the team really needs to agree on, and if they don't, you can find youself with uncommitted stakeholders, an unstable product, and other things that can drive up cost, nevermind drive you mad in the process. With that in mind, consider defining Test Readiness criteria that can be agreed to by all stakeholders.  With that defined, everyone can have a more objective view of what is expected during team planning/scheduling sessions.  Prior to each scheduled testing event, hold a short meeting and review the criteria with all stakeholder to detemine whether or not you are actually ready.  Test Readiness Reviews (TRR) are generally designed to assess the teams readiness based on a variety of information, here are examples of things you may review in this type of meeting: 

• Software requirements changes
• Design Changes
• Standards Compliance
• Security
• Test Plan(s)
• Test procedures
• Unit test procedures and results
• Problem/Defect/Change reports (pending test/verification)
• Any changes to associated software products
• Etc, etc, etc...

Whatever you decide to do, remember to write it down, publish it, and refer to when building Agenda's for test readiness reviews...

Tags: processes

Recently I released a product to one of my customers for a preview (e.g. Alpha Release) and not too long after I starting getting calls with complaints regarding incomplete functionality... As you can image I stated it was Alpha and I might as well have been speaking elvish because they just didn't understand.  Lucky for me, this term was spelled out pretty clearly in the Software Requirements Specifications (SRS) I wrote at the beginning of the project which we all agreed to. This type of thing is crucial and you really need to define threshholds for your releases in writing and do as much as possible to make the definitions comprehensive.  Over the years I have found a lot of different definitions for caveats such as Alpha, Beta, Candidate Release, Etc...  However you define it, write it down and make sure everyone agrees.  Here is what I wrote in my SRS...

PRODUCT TESTING AND SOFTWARE PRERELEASE PROVISIONS

Testing shall occur using a test team coordinated by the customer as well as internal testing coordinated by the software development team. The team shall test the product(s) and evaluate its functionality and capabilities as they apply to the current state of the development life cycle. The pre-release test group(s) shall provide information concerning software changes (enhancements and defects) through the Configuration Control Board (CCB) and test event hot-wash meetings as applicable. For details on project test procedures and methods, refer to the project Test Plan.  The following pre-release testing phases are defined for this project:

• Alpha Release testing is the first phase of testing in a software development process. This phase includes unit testing, component testing, and limited system testing. This is generally an internal test cycle and is accomplished using an Alpha Release of the product.
• Beta Release testing is the phase of software testing in which a sampling of the intended audience uses the product(s). This phase of testing may also include a number of specialized tests designed to identify areas of the product needing improvement (Ex. Security, Performance, Scalability, etc…). Beta testing is considered "pre-release testing" and is accomplished using a Beta Release of the product.
• Candidate Release testing (A.K.A. Production/Acceptance Test Releases) are software releases prior to the final production of the software. In this phase of testing all stated requirements should have been met. The customer’s acceptance testing is often conducted with this release and is accomplished using a Candidate Release of the product.

The aforementioned external tests are designed; among other things; to verify and/or validate the products development. For the purposes of this document, verification is meant to answer two primary questions with respect to the product being tested.

• "Are we building what we were asked to build?"
• "Are we building it right?"

Verification is accomplished as part of unit testing, integration testing, systems testing, Function Qualification Test (FQT), and more. For the purposes of this document, validation is meant to answer two primary questions with respect to the product being tested.

• "Are we building what the operator needs?"
• "Are we building the right thing?"

Validation is primarily accomplished as part of acceptance testing although valuable insight can be gained by including a diverse set of end-users in Beta testing.

The provisions below identify the scope of each pre-release product and the test phases they support.

Alpha Release
Alpha releases are software releases made prior to any Beta release or Beta test phase. This release of the product is not yet stable and will lack many features. Alpha software is only released to provide for targeted analysis, design reviews, prototyping, or early product demonstrations. Alpha releases shall not be used to fully assess any level of compliancy to stated requirements or goals; however this release may be used to validate the approaches selected. Alpha releases are internal releases and should never be released to third parties. After some testing and some revision, the product will assume beta status.

• Alpha Test Phase
  Alpha releases are versions of a new product still in development and represents the first phase of testing in a software development process. This phase includes unit testing, component testing, and limited system testing. This is an internal pre-release test cycle. The first Alpha release marks the beginning of the Alpha Test Phase.

Beta Release
Beta releases are versions of a new product still in development, which is provided to external operators for testing. Beta releases are not produced until sometime after bug convergence has been observed. Bug convergence is the point at which the development team has made measurable progress against the active bug count; which is the point at which the rate of bugs resolved exceeds the rate of bugs reported. Many bugs are usually eliminated at the earlier Alpha stage of development and testing, however bugs will still be present in Beta releases. Beta testers use the software to do real work and report any bugs or badly implemented features they find. Beta releases may be used to assess levels of compliancy as it is related to the stated requirements and/or goals; however, it is often limited to a subset of requirements for which the beta was released. While Beta releases are; by definition; releasable to the “public” they should only be distributed to a limited number of expert operators in the earliest phases. Distribution of beta versions allows operator testing and feedback to the developer, so that any necessary modifications can be made before final product release. The term Beta release is given to a product that is not ready for public consumption, but is good enough for a wider testing scope. By the end of a beta test, all major bugs should have been discovered and repaired. Generally, beta testing is considered to be the final pre-release stage of the tests, and includes experienced testers external to the developing organization.

• Beta Test Phase
  The Beta test release marks the beginning of the Beta Test Phase. Beta Testing is the second phase of testing in which a sampling of the intended audience tries the product out. Beta testing is considered an external pre-release test cycle.

Candidate Release
The Candidate Release (A.K.A. Production/Acceptance Test Release) is a software release made prior to the final production of the software. In this phase of development all stated requirements should have been met or mitigated to a final status. Candidate Releases are not produced until the project has observed a Zero-bug bounce. Zero-bug bounce is the point when development has resolved all bugs raised by testing and no active bugs remain. The customers acceptance testing is often conducted with this release, which may include a wide range of testing models (e.g. usability, security, performance, etc…) needed to fully validate the product. This is still considered a pre-release product pending final release approval from the customer.

• Production Test Phase
  The Production test phase is the final phase of testing prior full release of the product in which the customer performs final acceptance testing. Particular attention is placed on media (re)production methodologies, software installation routines, and documentation.

Tags: requirements, processes

So it was that time again...  Time to write requirements for a new project.  Depending on your environment and the complexity of the anticipated solution this can be a really tedious piece of work.  As with most efforts such as this you need to try and create a common vernacular.  This is really crucial to ensuring you have requirements that are objective and agreeable. Here are a couple of examples.

Software Requirements Validation Criteria 

The requirements defined in the Software Requirements Specification (SRS) are evaluated with respect to the following criteria. This criterion is not intended to compete but is provided to clarify language usage between project stakeholders:

• Correct. The SRS is correct if and only if every requirement stated therein represents something required of the system to be built.
• Unambiguous. The SRS is unambiguous if and only if every requirement stated therein has only one interpretation.
• Complete. The SRS is complete when it encompasses the following four qualities: 
  • Everything that the software is supposed to do is included in the SRS.
  • Definitions of the responses of the software to all classes of input data in all classes of situations are included.
  • All artifacts related to the requirement are properly identified and referenced.
  • No sections are marked as To Be Determined (TBD).
• Verifiable. The SRS is verifiable if each requirement can be implicitly or explicitly tested. Every attempt should be made to minimize the number of implicitly tested requirements.
• Consistency. The SRS is consistent if it uses the same terminology throughout.
• Modifiable. The SRS should be written in such a way that requirements can be easily added, changed, and deleted. Establish criteria for how this will be accomplished in the Overview section of the SRS.
• Externally Consistent. The SRS is externally consistent if and only if no documented requirement conflicts with the Statement of Work, System Requirements, or other projectspecific controlling documents.
• Internally Consistent. The SRS is internally consistent if and only if no documented requirement conflicts with another documented requirement.
• Traceable. The SRS should be traceable to the system/software specification which is provided by the customer. Each requirement shall identify its source.
• Design-independent. The SRS cannot contain any design dependent requirements.
• Concise. The SRS should contain only the necessary verbiage. Elimination of excess wording is critical for conciseness. Use of compound expressions (e.g. X and Y) shall also be avoided.

Best Practice Guidelines for Authoring Requirements

This project used the natural language specification for authoring requirements. The natural language approach requires only moderate training for those specifying the requirements and no, or very little, training for those who use the specification (e.g., software designers, programmers, testers, etc…). In general, each requirements statement shall address the following elements:

• localization
• entity
• action
• target
• constraint

The following example requirement statement exhibits all five of the elements:

"When the user selects the 'Check-Out' document function on the Document Control Page, the Document Control Page shall launch the most recent document revision in its native application unless the Document Control Page is empty (i.e., has no document revisions)."

• localization - When the user selects the 'Check-Out' document function on the Document Control Page
• entity - the Document Control Page
• action - launch
• target - the most recent document revision in its native application
• constraint - unless the Document Control Page is empty (i.e., has no documents revisions)

The following bullets provide some additional guidance for developing sound requirements statements:

• Avoid weak phrases, such as:
  • as appropriate
  • may
  • if required
  • if practical
  • at a minimum
  • be able to
  • capable of
  • not limited to
  • as much as possible
• Avoid imprecise words, such as:
  • simply
  • quickly
  • efficiently
  • friendly
  • timely
  • easy
  • normal
  • adequate
  • effective
• Avoid generalities, such as:
  • large
  • many
  • most
  • near
• Use the correct imperative verb:
  • shall - prescribes
  • will - describes
  • must - constrains
  • should - recommends
  • may - permits
  • can - indicates capacity/ability/possibility
• Avoid compound statements such as ‘Shall do X and Y’ or ‘Shall include X, Y, Z’. This type of stated requirement should be split into separate requirements (Ex. Shall do X, Shall do Y, Shall include X, etc…) unless it is an all or nothing requirement
• Do not use different words to refer to the same thing, for example:
  • computer screen and computer monitor
  • window frame and window pane 

Note: The use of the terms SHOULD and SHALL are guided by RFC 2119. If you find yourself writing requirements formally; or otherwise; this is worth a read.

Each statement should be accompanied by the source of the requirement and the date it was entered. If the source is a person (e.g., from a meeting, an informal conversation with the customer or customer representative, or a requirements elicitation session), the source should review the requirements statement once documented.

Tags: requirements, processes