Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!


Data Flow Diagram (DFD) Tutorial: Texas Hold ‘Em

Software Requirements Blog - - Thu, 07/31/2014 - 17:11
The data flow diagram is a useful, low-level data model that can show how data is transformed and manipulated through processes. This model does NOT show decisions, and nor does it show a sequence of processes. This tutorial will take a commonly understood real-world scenario, a round of Texas Hold ‘Em, and provide step-by-step instructions […]
Categories: Requirements

2 minute models: A walk through the Feature Tree Model

Software Requirements Blog - - Tue, 07/29/2014 - 19:41
Please join me for a quick walk through of our Feature Tree Model. This video only scratches the surface of how valuable this model really is, and how it can be used for a variety of projects. Please feel free to make suggestions and ask questions in the comments section, and I will address them […]
Categories: Requirements

Software Development Conferences Forecast July 2014

From the Editor of Methods & Tools - Mon, 07/28/2014 - 08:39
Here is a list of software development related conferences and events on Agile ( Scrum, Lean, Kanban) software testing and software quality, programming (Java, .NET, JavaScript, Ruby, Python, PHP) and databases (NoSQL, MySQL, etc.) that will take place in the coming weeks and that have media partnerships with the Methods & Tools software development magazine. Agile on the Beach, September 4-5 2014, Falmouth in Cornwall, UK SPTechCon, September 16-19 2014, Boston, USA Future of Web Apps, September 29-October 1 2014, London, UK STARWEST, October 12-17 2014, Anaheim, USA JAX London, October 13-15 2014, ...

Quote of the Month July 2014

From the Editor of Methods & Tools - Fri, 07/25/2014 - 08:22
Research has shown that the presumption of selfishness is true for maybe 30% of most populations; another 50% are reliably unselfish, and the remaining 20% could go either way, depending on the context. If a company presumes that the undecided 20% are selfish, you can bet they will be selfish—it’s a self-fulfilling prophecy. But worse, the company will create an environment where the 50% of the people who are unselfish are forced to act selfishly. And losing the energy, commitment, and intelligence of half the workforce is perhaps the biggest ...

The Robotic Jockey

Software Requirements Blog - - Wed, 07/16/2014 - 12:18
In the March 1945 issue of “Radio-Craft”, a bold vision was laid out for the future of horse racing: human jockeys should be replaced by motorized, radio-controlled “Robotic Jockeys”.   Taken from the same article, the author describes how these new jockeys would work: “The “jockey” would consist of a modern radio receiver, with outputs […]
Categories: Requirements

Don’t Begin UAT Until

Software Requirements Blog - - Tue, 07/15/2014 - 12:20
As projects run long and budgets get tight, the first thing that gets squeezed is testing. Even with the best of intentions, the planning, design, and development phases often go longer than expected. In order to meet that precious target rollout date, testing can get rushed. However, it is really important that testing is done […]
Categories: Requirements

Should the Product Owner test everything?

Good Requirements - Jeffrey Davidson - Thu, 07/10/2014 - 00:24

A scrum master I’ve coached recently sent me this question and I wanted to share my answer. Would you have answered the same way? What did I miss? What do you ask (demand?) from your product owner?


Question: Hi, Jeffrey,

Quick question for you: Does Product Owner (PO) approval need to be on a per story basis, per feature basis, or both?

We are facing a situation where some of the system environments were not in place and completed work has remained in Dev until today. We received today that the Test environment is ready. The stage environment is due to be completed at some point in the near future. Meanwhile, our team has modified the team’s “Definition of Done” so that completion criteria are more aligned with our capabilities within the framework of system environments being incomplete. Hence, the above question.

The Client


Answer: Hello, Client.

First, it makes sense the PO is included in the conversation around “Definition of Done.” I’m not sure based on the question if they are in the loop, or not. I say this because the team is building and meeting expectations for the PO. It’s the polite thing to do to notify them and explain the new definition. In some cases, it may be more appropriate to ask their permission to change rather than simply notify them of the change.

Second, this change makes sense to me; you didn’t have the right environments previously and now you do. It makes sense the definition should change to accompany the environment and how the team is working.

Third, what’s happened to date and how much trust is there between the PO and team? If the PO has already tested all the existing stories, then they may not want to do more than audit the existing stories in the new environment(s). If the PO has trust in the team and testers, they many never do more than audit the stories. If the PO doesn’t have time, they may never get to more than auditing stories. In the end, it’s a great big “it depends” kind of answer.

What do I want from the PO? I want more involvement, as much as I can get. I want the PO to test every story as it’s finished and at least audit functionality and features as they are delivered. I don’t often get it, but it’s my request.

Categories: Requirements

How do I split these 40 stories?

Good Requirements - Jeffrey Davidson - Fri, 06/27/2014 - 04:15

A student from last week’s Agile Bootcamp Class taught at Harvard University (yes, that Harvard) asks,


Question: I have a project that involves 3 different users who want approximately 25 new fields on an application. Most of these fields are view only with the exception of 4-5 fields which allows input changes. However, user #1 wants to see all 25 fields, user #2 wants to see only 10 of the same fields, and user #3 wants to see 5 of the same fields. How should I approach writing these stories? Would I write a story for each user and each field – which could potentially be 40 stories? Or should I just combine the fields that all 3 users would want to view? For example, one field might be “name”. My user story might say“As a user #1, user #2, user #3, I want to see all names of employees eligible for an annual salary increase so that I can view all eligible employees.”


Answer: This sounds like an interesting set-up. My answers, of course, will be a bit general because I don’t know all the specifics. Also, I will make more stories if the developers are unfamiliar with the systems / tables / data, and probably fewer stories if the team knows quite a bit about the different systems. With caveats out of the way, let’s dig in! First, 40 stories? Yuck. Too many. Second, because you have 3 different users, I would start with stories for satisfying all of them (unless there is a reason to focus on just one). My presumption is doing this adds value the quickest, which is my guiding answer for how to break up stories.

  1. As user #3, I want to view < information from 1 field> so I can do my job.
  2. As user #3, I want to see < more information > so I can . . . .
  3. As user #2, I want to view < even more information > so I can . . . .
  4. As user #1, I want to see < all the information > so I can . . . .

The point of #1 is to prove we can display information, while the other stories add more details for the same and additional users. None of these is about editing the data. Depending on what keeps the users and developers happiest, there are a couple of options. I can insert story 1A; Edit the first field. After this I would insert more edit stories, probably grouped like the last 3 stories above, as appropriate. A different approach might be to insert the edit stories after the last story. Again, where is the value?

A couple side notes:
  • It doesn’t make much difference if you use “see” or “view,” the goal is understanding, not the worlds best grammar.
  • I would be remiss if I didn’t mention the value statement in your user story is a bit weak. What is the specific reason to view eligible employees; the actual awarding of salary increases, a validation check, a fascination with other people’s salary, something else entirely?
Categories: Requirements

Software Development Conferences Forecast June 2014

From the Editor of Methods & Tools - Thu, 06/26/2014 - 07:22
Here is a list of software development related conferences and events on Agile ( Scrum, Lean, Kanban) software testing and software quality, programming (Java, .NET, JavaScript, Ruby, Python, PHP) and databases (NoSQL, MySQL, etc.) that will take place in the coming weeks and that have media partnerships with the Methods & Tools software development magazine. AGILE2014, July 28 – August 1, Orlando, USA Agile on the Beach, September 4-5 2014, Falmouth in Cornwall, UK SPTechCon, September 16-19 2014, Boston, USA STARWEST, October 12-17 2014, Anaheim, USA JAX London, October 13-15 2014,London, UK Pacific Northwest ...

Kanban, Developer Career & Mobile UX in Methods & Tools Summer 2014 issue

From the Editor of Methods & Tools - Mon, 06/23/2014 - 14:54
Methods & Tools – the free e-magazine for software developers, testers and project managers – has just published its Summer 2014 issue that discusses objections to Kanban implementation, How to use a model to evaluate and improve mobile user experience, balancing a software development job and a meaningful life, Scrum agile project management tools, JavaScript unit testing and static analysis for BDD. Methods & Tools Summer 2014 contains the following articles: * Kanban for Skeptics * Using a Model To Systematically Evaluate and Improve Mobile User Experience * Developer Careers Considered Harmful * TargetProcess – ...

Quote of the Month June 2014

From the Editor of Methods & Tools - Fri, 06/20/2014 - 06:39
A UX team that deals with only the details of radio buttons and check boxes is committing a disservice to its organization. Today UX groups must deal with strategy. Source: Institutionalization of UX (2nd Edition), Eric Schaffer & Apala Lahiri, Addison-Wesley

Business Analytics: Requirements for Data Transformation

Software Requirements Blog - - Thu, 06/19/2014 - 12:29
There is a major change happening in the IT industry — the use of big data and analytics to guide how businesses are run. Many companies are embracing analytics as part of their core strategies. Unfortunately, some of those companies think that they can just purchase an analytics solution, implement it, load and collect data, […]
Categories: Requirements

Long Distance Agile – How Good Requirements Documentation Overcomes the Problems of Distance and Disconnected Agile Teams

Software Requirements Blog - - Wed, 06/18/2014 - 12:31
In the last three months or so, I have been approached by a number of analysts and developers struggling with the problems of working on geographically dispersed Agile teams.  In a majority of the situations, the team members are scattered in countries on different sides of the globe with a minimum of 6 hours or […]
Categories: Requirements

Product Management in Small, Medium, and Large Companies

Software Requirements Blog - - Tue, 06/17/2014 - 12:49
While at Product Camp Silicon Valley, there was a presenter who had a great idea of discussing the differences within Product Management at small, medium, and large companies. This discussion was slightly sidetracked by a few people who had clear opinions and agendas instead of wanting an open discussion forum, valuing each person’s experience as […]
Categories: Requirements

Software Development Linkopedia June 2014

From the Editor of Methods & Tools - Thu, 06/12/2014 - 17:08
Here is our monthly selection of interesting knowledge material on programming, software testing and project management.  This month you will find some interesting information and opinions about Agile project estimation, JavaScript frontend testing and refactoring, retrospectives, software configuration, Test-Driven Development, software tools and NoSQL databases. Blog: Calculating Velocity FAQ Blog: Writing Testable Frontend Javascript Part 1 – Anti-patterns and their fixes Blog: Writing Testable Frontend Javascript Part 2 – Refactor away anti-patterns Blog: Creating options by slicing features – #NoEstimates technique Article: Agile Retrospectives: Why They Matter Article: First Sketches of an App: Planning the Design ...

An Exercise in Documenting Current State: Reddit and the Decision Tree

Software Requirements Blog - - Thu, 06/12/2014 - 12:27
An exercise in documenting current state: reddit and the decision tree In an earlier post I detailed how you can use RML models to document the current state of your systems and processes by using a Business Data Diagram to illustrate the hierarchy and relationship of objects on the popular content website In this […]
Categories: Requirements

Amazon Dash: Nifty New Technology or Great Product Management?

Software Requirements Blog - - Wed, 06/11/2014 - 12:48
This weekend I learned about a cool new gadget made by Amazon: the Amazon Dash. This device pairs with your AmazonFresh account (an account for local delivery of groceries- available only in certain locations) and allows you to stock your online grocery list by speaking your food’s name or by scanning the barcodes you have […]
Categories: Requirements

Lightweight agile only needs 2 goals

Good Requirements - Jeffrey Davidson - Tue, 06/10/2014 - 23:14

Most of the time, developers want to deliver useful software. They want their business partners and end users to be happy, even delighted to use their software. They struggle with this. Sometimes forget this. I haven’t worked with everyone, but for every developer I have worked with and gotten to know, this is true.

Given this, a desire to make customer happy with useful and delightful software, what would I do if I went back into IT management? If the desire was right and the software development practices were not effective, then I think I would introduce 2 ideas. I would not send everyone to agile training. I would not introduce stand-ups, paired programming, or burn-down charts. I would not change the language. All of that is too difficult. Too heavy.

What 2 ideas would I introduce to my team? I would insist on just 2 things. Here’s what I might say . . .

First I want us to develop a new review & feedback system. On a regular basis, we need to review what we’re doing and figure out how to do it better. Sometimes this would cover the last hour, when we where in a meeting. Sometimes it would cover the day, so tomorrow will be more effective. Sometimes it will cover a week or one month, so we make sure we capture the big and important issues. And to make sure we are on the right track we will also hold an annual review to check our overall direction and strategy, too.

Second I want us to start integrating code into the trunk multiple times a day. Anything less than twice a day means you’re in too many meetings! The reason for doing this is to reduce risk, because if you’re spending time working in a silo then you are adding or ignoring risk.


So, why these 2 ideas? Why did I ignore the rest of the principles surrounding the agile manifesto? Because everything the agile manifesto wants is covered in these two ideas. I am both forcing change and giving them a means to talk about the problems and incorporate the differences into their processes.

The first idea I will introduce is all about giving them the foremost thing a team or company, an individual or company needs is the ability to review it’s process and work, to honestly assess the output and performance, and be able to improve upon what they’ve done.

The second idea I will introduce is all about forcing fast feedback. Jez Humble has said, “If it hurts, do it more frequently and bring the pain forward.” It was counter-intuitive for me, but I finally learned he is right. We need to stop avoiding the painful parts of the process because we are making it worse. For example, if integration is difficult, waiting makes it more so. Do it so often the issue becomes irrelevant.

By requiring continuous integration as my second idea, I force the team to look at their environments, their tools, their permission structures, their process, their tests, their requirements, and more. Each change will cascade other changes, and in so doing, push the group to accommodate the greater needs. We may never call what we do “agile” even though I expect, with some time, we will be living the agile dream!


Okay, this is my dream. What do you think? What’s missing? Can you convince me even these 2 steps are too heavyweight?

Categories: Requirements

Managing Complexity

Software Requirements Blog - - Tue, 06/10/2014 - 12:38
“Complexity” is characterized by lots of different interconnected parts, physical or otherwise. The human body is complex; a single-celled organism is not (well, not as complex, anyway). The problem with complexity is that in any system, each component is potentially affected by each other component. That means adding any single component to a system exponentially […]
Categories: Requirements

How Can IT Success be Measured Independent of Project Success?

Software Requirements Blog - - Mon, 06/09/2014 - 12:24
I am on the opinion that there is a clear difference between overall project success and the performance of the IT team associated with the project.  You can find my detailed discussion on this viewpoint here. Given that there is a fundamental dichotomy in the outcomes between the related and symbiotic efforts of the Business […]
Categories: Requirements