Warning: Table './devblogsdb/cache_page' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_page WHERE cid = 'http://www.softdevblogs.com/?q=aggregator/categories/6&page=5' in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc on line 135

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 729

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 730

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 731

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 732
Software Development Blogs: Programming, Software Testing, Agile, Project Management
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!

Project Management
warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/common.inc on line 153.

Project Management is a Closed Loop Control System

Herding Cats - Glen Alleman - Sat, 01/23/2016 - 23:27

Without a desired delivery date, target budget, and expected capabilities, a control system is of little interest to those providing the money at business level. There is no way to assure those needs – date, budget, capabilities – can be met with the current capacity for work, efficacy of that work process, or budget absorption of that work. 

With a need date, target budget, and expected capability outcome, a control system is the basis of increasing the probability of success. These targets are the baseline to steer toward. Without a steering target the management of the project is Open Loop. There are two types of control systems

  • Closed Loop Control – where the output signal has direct impact on the control action.
  • Open Loop Control – where the output signal has no direct impact on the control action.

An Open Loop Control control system is a non-feedback system, where the output – the desired state – has no influence or effect on the control action of the input signal. In an Open-Loop control system the output – the desired state– is neither measured nor “fed back” for comparison with the input.  An Open-Loop system is expected to faithfully follow its input command or set point regardless of the final result. An Open-Loop system has no knowledge of the output condition – the difference between desired state and actual state – so cannot self-correct any errors it could make when the preset value drifts, even if this results in large deviations from the preset value.

An Closed-loop Control System, is a feedback control system which uses the concept of an open loop system as its forward path but has one or more feedback loops between its output and its input. In Closed Loop control, there is a “feedback,” signal that means some portion of the output is returned “back” to the input to form part of the systems excitation.

Closed-loop systems are designed to automatically achieve and maintain the desired output condition by comparing it with the actual condition. Closed Loop control systems do this by generating an error signal which is the difference between the output and the reference input. A “closed-loop system” is a fully automatic control system in which its control action being dependent on the output in some way.

Key Differences Between Open Loop and Closed Loop control

Open Loop Control

  • Controller has some knowledge of the output condition.
  • The desired condition is not present in the control loop – hence the Open Loop.
  • Any corrective action requires an operator input to change the behavior of the system to achieve a desired output condition
  • No comparison between actual output condition and the desired output conditions.
  • Close Loop control has no regulation or control action over the output condition ! Each input condition determine a fixed operating condition for the controller.
  • Changes or disturbances in external conditions does not result in a direct output change unless the controller and manually altered.

Closed Loop Control

  • Controller has some knowledge of the output condition.
  • The desired condition is compared to the actual condition to create an error signal. This signal is the difference between the input signal (the desired dryness) and the output signal (the current dryness).
  • Closed loop means feedback not just for recording the output, but for comparing with the desired state to take corrective action.
  • Output condition errors are adjust by changes in the controller function by measure difference between output and desired condition.
  • Output conditions are stable in the presence of an unstable system.
  • Reliable and repeatable output performance results from corrective actions taken from the error signal.

Using Closed Loop Control for a Project

  • The Setting – we work in an enterprise IT environment, a product development company, or on a mission critical software project.
  • The Protagonist – Those providing the money need information to make decisions
  • The Imbalance – it’s not clear how to make decisions in the absence of information about, the cost, schedule, and technical outcomes from those decisions.
  • Restoring the Balance – when a decision is made, it needs to based on the principles of microeconomics, at least in a governance based organization. The decision
  • Recommended Solution – start with a baseline estimate of the cost, schedule, and technical performance. Execute work and measure the productivity of that work.

Using these measures to calculate the variance between planned and actual. Take management action to adjust the productivity, the end date, the budget – using all variables produce a new Estimate To Complete to manage toward.

This is a closed loop control system

The Microeconomics of Decision in Closed Loop Control

Microeconomics is the study of how people make decisions in resource-limited situation on a person scale. It deals with decision that individual and organizations make on such issues as how much insurance to buy, which word processor to buy, what prices to change for pro ducts and services, which path to take in a project. Throughput the project lifecycle, these decision making opportunities. Each decision impacts the future behavior of the project and is informed by past performance and the probabilistic and statistical processes of the underlying project activities. To make an informed decision about the project, estimates are made using this information.

Microeconomics applied to projects is a well understood and broadly applied discipline in cost account and business strategy and execution. Decision making based on alternatives, their assessed value and forecast cost. Both these values are probabilistic. Microeconomics is the basis of Real Options and other statistical decision making. Without this paradigm decision are made not knowing the future impact of those decisions, their cost, schedule, or technical impacts. This is counter to good business practices in any domain.

Let's Look At An Open Loop Control System

Screen Shot 2016-01-23 at 3.17.28 PMThis is all fine and dandy. But where are we going? What's the probability we will arrive at our desired destination if we knew what that destination was? Do we have what we need to reach that desired destination if we knew what it was? In Open Loop Control these questions have no answers.

Let's Look at a Closed Loop Control System

Screen Shot 2016-01-23 at 3.18.42 PM

We want to manage our projects with Closed Loop Control Systems

Related articles Who's Budget is it Anyway? Your Project Needs a Budget and Other Things The Actual Science in Management Science Control Systems - Their Misuse and Abuse Building a Credible Performance Measurement Baseline Open Loop Thinking v. Close Loop Thinking
Categories: Project Management

Forecasting Cost and Schedule Performance in the Presence of Uncertainty

Herding Cats - Glen Alleman - Fri, 01/22/2016 - 17:28

Estimating in the presence of uncertainty is a critical success factor for all project work. Uncertainty prevails on all projects, no matter the domain, development process, or governance method.

Uncertainty from underlying statistical variances. Uncertainty from probabilistic events.

Here's an approach to estimating the cost and schedule impacts from those uncertainties.

Forecasting cost and schedule performance from Glen Alleman


Related articles Intellectual Honesty of Managing in the Presence of Uncertainty Essential Reading List for Managing Other People's Money
Categories: Project Management

Risk Management is How Adults Manage Projects

Herding Cats - Glen Alleman - Wed, 01/20/2016 - 19:44

Risk Management is How Adults Manage Projects - Tim Lister

Tim's quote offends some people. Here's a collection of his presentations. But this not really the point of this blog. I'm working two programs where Agile (Scrum and SAFe) is integrated into the Earned Value Management System, complaint with EIA-748-C and the guidelines for deploying, using, and reporting progress to plan with that system. This integration is directed by FAR 34.2 and DFARS 234.2 on Software Intensive System of Systems programs.

These programs are similar to Enterprise IT programs, they have mission critical outcomes, they are expensive, they have high risk, they are not simple structure - by definition, and they have deadlines and budget goals set of the enterprise for maintenance of corporate performance.

Outside of the programs we work, we encounter much confusion around risk management, the source of risk, and the separation of the effective and non-effective process of managing risk in the presence of uncertainty. Let's start with a framework for making decisions in the presence of uncertainty. This briefing has been shown before here, many times. But it can't be shown too many times, because there is much misinformation about how to manage in the presence of uncertainty. This briefing is part of a much large set of charts developed over several years for an Office of Secretary of Defense for Acquisition, Technology and Logistics. These are the people that buy things for the warfighter and those who support them.

It may not appear to be applicable in all domains, but I'd strongly suggest it is. Because uncertainty is present on all projects. And the risk this uncertainty creates is present on all projects. Uncertainty and the resulting risk cannot be avoided it can only be managed.

The Point

When we hear Agile is Risk Management it's not true. Agile Software Development in the form of Scrum, XP, DSDM, Crystal, and now even Agile Prince2 is just that - a Software Development Method using the principles of agile.

12 Agile Principles

In some domains by the way a few of those principles are violations of governance of other people's money. Many business people have day jobs and aren't going to be available on demand to work with the developers.  standards - DODAF, ToGAF, 1553 Bus, ISO 12207 etc. define architectural processes.

But that aside for now, Agile provides information for risk management through frequent feedback and adaptability. But Agile is NOT risk management for a  simple reason ...  

Agile does not model the uncertainties that underly all project work.  

Agile has no notion of margin. Agile has an informal notion of risk reduction of Reducible Risks (Epistemic uncertainties if you read the briefing). But those irreducible uncertainties (Aleatory) are not addressed by Agile. Research shows the irreducible uncertainties are the killer problems on all project work. These come from the natural variances of humans, processes, and machines.

Screen Shot 2016-01-20 at 8.08.24 AM

Agile in the form of methods has no process model for addressing the reducible and irreducible uncertainties other than to provide data on performance to date to make decisions about mitigations, margin, and management reserve needed to MANAGE Risk in the presence of uncertainty. 

And of course the final tag line

To Manage Risk in the presence of uncertainty we must Estimate not only the probability of occurrence of an Event based risk, but also Estimate the statistical processes of naturally occurring variances and then estimate the impact of those uncertainties creating risk, Estimate the cost and schedule to mitigate those risk, and finally Estimate the residual uncertainty after mitigation.

Yes, Risk Management is How Adults Manage Projects and of course Estimating is how Adults Manage Projects


Related articles Agile Software Development in the DOD Risk Management is How Adults Manage Projects What Do We Mean When We Say "Agile Community?" IT Risk Management
Categories: Project Management

Does a Scrum Team Need a Retrospective Every Sprint?

Mike Cohn's Blog - Tue, 01/19/2016 - 16:00

The Scrum sprint cycle calls for a team to do a retrospective at the end of each sprint. Yet in almost every Certified Scrum Master course I teach, I'm asked if teams really need to do a retrospective every sprint.

Usually the logic of the questioner is along the lines of:

  • Our team is so good, we rarely come up with anything to improve at, so we want to stop.
  • We find retrospectives boring, so we want to stop.
  • We're too busy with real work (or retrospectives take too long), so we want to stop.
  • We simply don't like retrospectives, so we want to stop.

So, in this blog post, I want to briefly counter each of those arguments and say why you should still do a retrospective every sprint. Then, I'll end the post by saying maybe--just maybe--you don't really need to do a retrospective every sprint after all. (Did I surprise you with that? Read on ...)

The Team Is Too Good for Retrospectives

Your team is not too good that it cannot get better. I’ve worked with teams that have been doing Scrum for over 10 years, doing retrospectives every two weeks, and they can still identify ways to improve. It is highly unlikely that your team is so good there are no further improvements either to be identified or worth making.

Retrospectives Are Too Boring

No one said a retrospective should be as exciting as the latest Hollywood blockbuster. But there are things you can to do to liven them up.

For example, mix things up by asking a ScrumMaster from another team to facilitate your retrospective. The change in style can help. (Be sure to return the favor.) Change the venue, possibly holding a retrospective outdoors, even while walking.

Try a totally different format for the meeting. For example, many teams fall into a habit of always looking for new practices to adopt. Dedicate your next retrospectives entirely to discussing what should be dropped from the team’s process. (And, no, “dropping retrospectives” is not allowed.)

Geoff Watts and Paul Goddard offer ten different formats for retrospectives in their video course on retrospectives. Watch it and try some your team hasn’t tried. There are plenty of ways to prevent a retrospective from being boring.

The Team Is Too Busy for Retrospectives

A team that says it is too busy to dedicate time to getting better is taking a very shortsighted view of the future.

In his Seven Habits of Highly Effective People, Stephen Covey used the analogy of a woodcutter cutting a tree for days with a saw. Eventually the saw becomes dull. But with a short-term attitude, the woodcutter will never stop to sharpen the saw.

A Scrum team with a similarly short-term view will never take thirty minutes out of its schedule to look for improvements. Instead they’ll put too much value on the little bit of code that could have been developed during those 30 minutes.

The Team Doesn't Like Retrospectives

This is somewhat a variation on retrospectives being boring. I’ve listed it separately because it does go beyond retrospectives being boring or becoming mundane to some team members. Some team members just flat out don’t like them.

And for those team members, that may just be too bad because everyone on the team is expected to be a professional. And professionals do all parts of their jobs, not just the parts they want to do.

As soon as I finish writing this post, I need to rewrite it to make it better. That isn’t as fun. Then I need to proofread it. That’s not fun at all. Then I have someone else read it. And then I have to accept or reject edits to it. That’s not fun at all.

Not every part of our job gets to be fun. If some team members don’t like retrospectives, but if retrospectives are helping the team find ways to improve, the team should be doing them.

When It's OK Not to Do a Retrospective Every Sprint

But I also said I’d let you know when it’s OK not to do a retrospective every sprint. So, when is that?

If your team:

  • Is really good.
  • Has made significant efforts to make sure retrospectives aren't boring.
  • Is not too busy to invest in improvements that don’t pay them back immediately.
  • And understands the value of doing other than just the most pleasant work.

… and if they work in short sprints, I'll say it's OK for the team do retrospectives less frequently.

Here's why. The general Scrum rule is to run sprints of four weeks or less. So a team that truly wanted out of retrospectives could just adopt a four-week sprint.

Consider a team that has chosen one-week sprints for a variety of good reasons. But this team so detests retrospectives that they switch to a four-week sprint just to conduct retrospectives less frequently.

This would be a bad change, unless the change is appropriate for reasons other than just a desire to do retrospectives less frequently.

And so, a good ScrumMaster should really encourage the team to do retrospectives every sprint, arguing against the four objections covered above. But the ScrumMaster should be open in some rare cases to a team doing a retrospective perhaps every other sprint when using one- or two-week sprints.

I want to be clear that I always try to talk a team out of this. I always try to convince teams to do retrospectives every sprint. But if a team really has achieved a very, very high level of performance and is doing short sprints (usually one week), I am willing to acquiesce to their arguments.

I'll then have them do a retrospective every other sprint. And for most teams, that is more frequent than teams doing four-week retrospectives.

Come Back Next Week for My Favorite Way to Run a Retrospective

Be sure to come back next week. There are many ways to conduct a retrospective, but next week I’ll share my favorite way.

What Do You Think?

Let me know what you think in the comments below. Do you ever skip retrospectives? Under what circumstances do you think it’s OK (if ever)?

Four Tips to Writing Better and Faster

A colleague asked me for some tips about writing. With hundreds of articles, blog posts, and 10 books, I know what works for me. I suspect some of these ideas will work for you, too.

Tip 1:  Write every day.

Write for 15 minutes every day. This practice exercises your writing muscles. For me, it’s a little different than all the email I write :-)

Tip 2: Think about the stories you want to tell in an article.

People love stories. If you include a story, they will identify with it and love your work. That’s because they can identify with the situation, regardless if they agree with you.

You might not like my story approach. Think about what you like to read. What pulls you in? Write like that (not the same words, the same approach).

Tip 3: Writing is not editing.

For me, writing is about 3 parts:

  • Gather the ideas. If you want to outline, this is a great time to do it. Just remember that an outline is a guide, not rules.
  • Write down. 
  • Edit. This is where you use the red squiggly lines and the spell/grammar checker. I excise passive voice in my non-fiction. I look for a lower grade level (about 6 is what I aim for) and a high readability score. 

When I write (down), I don’t edit. I spew words on the page. It’s almost a game: how fast can I write? I write about 750-1000 words an hour. That’s pretty darn close to an entire article. (1000 words) After I’m done with the writing-down, I can edit. 

Tip 4: People will disagree with you

When you write non-fiction, people will disagree with you. (Heck, they probably disagree with fiction, too!) That’s fine. It’s their loss if they disregard your ideas. Everyone has their own experience. If you tell stories/provide tips/write from your experience, you are authentic. You also build your self-confidence. The writing is easier over time.

If you would like to practice your writing, I have an online workshop starting in March. See http://www.jrothman.com/syllabus/2015/12/writing-workshop-1-write-non-fiction-to-enhance-your-business-and-reputation/. You will write at least one article during the workshop. 

Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Tue, 01/19/2016 - 13:25

Great equations change the way we perceive the world. They reorchestrate the world - transforming and reintegrating our perception by redefining what belongs together with what. Light and waves. Energy and mass. probability and position. And they do so in a way that often seems unexpected and even strange.

- Robert P. Crease, The Greatest Equations Ever, Physics Web 2004, in The Mathematics Devotional: Celebrating the Wisdom and Beauty of Mathematics, Clifford A. Pickover

Categories: Project Management

Capabilities Based Planning

Herding Cats - Glen Alleman - Mon, 01/18/2016 - 19:21

I'm working two programs where Earned Value Management, through FAR 34.2 and DFARS 234.2 are applicable. These programs are also Software Intensive Systems applying Agile development processes. Capabilities Based Planning is defined as ...

A method involving the functional analysis of operational requirements. Capabilities are identified based on the tasks required… Once the required capability inventory is defined, the most cost effective and efficient options to satisfy the requirements are sought. Capabilities Based Planning is planning, under uncertainty, to provide capabilities suitable for a wide range of modern-day challenges and circumstances while working within an economic framework that necessitates choice.

In tradition Agile (I know agilest will be wincing) the development of requirements is emergent. On Sofware Intensive System of Systems in the domain where FAR / DFARS are applicable, we have deadlines and mandatory Capabilities for the outcomes of the work effort. The system must perform in specific ways on specific dates for specific costs.

This specificity of capabilities, cost, and delivery dates is no different than on Enterprise IT projects

When applying Agile Development has to address how do we bound the program in a contract vehicle? The Agile Manifesto of Customer Collaboration Over Contract Negotiation is fine except when dealing with a sovereign. So here's how its done.

Capabilities Based Planning

The needed Capabilities are on contract. The technical and operational requirements needed to provide those capabilities can be emergent and are suitable to agile development methods.

Here's some posts from the past about Capabilities Based Planning

And of course ...

To make decisions about the analysis of alternatives using Capabilities Based Planning, estimates must be made of the outcomes for each choice in the list of alternatives. Without estimates, there can be no Analysis of Alternatives to determine which capabilities are best suited to meet the mission need or fulfill the business case. There can be no credible decisions in the presence of uncertainty without estimates.

Related articles How Think Like a Rocket Scientist - Irreducible Complexity What Do We Mean When We Say "Agile Community?" Can Enterprise Agile Be Bottom Up? Seven Principles of Agile Software Development in the US DOD Two Books in the Spectrum of Software Development There is No Such Thing as Free Empirical Data Used to Estimate Future Performance Agile Software Development in the DOD Thinking, Talking, Doing on the Road to Improvement
Categories: Project Management

Software Development Linkopedia January 2016

From the Editor of Methods & Tools - Mon, 01/18/2016 - 15:44
Here is our monthly selection of knowledge on programming, software testing and project management. This month you will find some interesting information and opinions about organizational debt, product owner types, flat structures, mature developers, keeping your head cool, working with UX, technical requirements management, software architecture, group problem-solving techniques and thinking slow in software development. […]

2016 Reader Survey

Mike Cohn's Blog - Thu, 01/14/2016 - 16:00

I want to make sure I’m doing the best job I can addressing your needs and writing about the topics you’re interested in. And that means I need to know more about you. And so I’ve created a short survey. 

I’d really appreciate it if you’d take a few minutes to fill out the survey. By doing so, you’ll help me provide you with the best content I can.

There are only 10 questions, so you can finish in just a couple minutes and the results are completely anonymous.

Thanks in advance for your help.

Public Workshops in 2016

I have several public workshops this year.

I’m offering the Influential Agile Leader with Gil Broza April 6-7, 2016 in Boston and May 4-5, 2016 London. If you have not read some of my writing about leadership, take a look at these previous newsletters:

â–Ş Lead Your Agile Transition Through Influence
â–Ş Creating an Environment of Leadership
â–Ş Discovering Your Leadership

Early bird registration for Influential Agile Leader ends Feb 29, 2016.

In addition, I am offering these online workshops in March:
* Practical Product Ownership
* Writing Non-Fiction Workshop 1

Super early bird registration ends January 15, 2016.

I hope you decide to join me and we can learn together.

Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Tue, 01/12/2016 - 16:52

There is no problem so complicated that you can't make it worse - a common phrase in the astronuaght business

Categories: Project Management

Social Side of Code, Database CI and REST API Testing in Methods & Tools Winter 2015 issue

From the Editor of Methods & Tools - Mon, 01/11/2016 - 14:29
Methods & Tools – the free e-magazine for software developers, testers and project managers – has published its Winter 2015 issue that discusses the social side of code, database continuous intergration and testing REST API. Methods & Tools Winter 2015 issue content: * Meet the Social Side of Your Codebase * Database Continuous Integration * […]

Quote of the Day

Herding Cats - Glen Alleman - Mon, 01/11/2016 - 00:47

The impression that "our problems are different," is a common disease that afflicts management to work over. They are different, to be sure, but the principles that will help improve the quality of product and service are universal in nature - W. Edwards Deming

So when we hear some new and controversial conjecture is the solution to the smell of dysfunction, ask for tangible, testable, verifiable evidence that this new approach is not a solution looking for a problem to solve. 

Categories: Project Management

Can a Traditional SRS Be Converted into User Stories?

Mike Cohn's Blog - Tue, 01/05/2016 - 16:00

A lot of traditionally managed projects begin with a Software Requirements Specification (SRS). Then sometime during the project, a decision is made to adopt an agile approach. And so a natural question is whether the SRS can serve as the newly agile project's product backlog. Some teams contemplate going so far as rewriting the SRS into a product backlog with user stories. Let's consider whether that's necessary.

But before taking up this question, I want to clarify what I mean by a Software Requirements Specification or SRS. I find this type of document to vary tremendously from company to company. In general, though, what I'm referring to is the typical document full of "The system shall ..." type statements.

But you can imagine any sort of traditional requirements document and my advice should still apply. This is especially the case for any document with numbered and nested requirements statements, regardless of whether each statement is really written as "the system shall ..."

Some Drawbacks to Using the SRS as a Product Backlog

On an agile product, the product backlog serves two purposes:

  • It serves as a repository for the work to be done
  • It facilitates prioritization of work

That is, the product backlog tells a team what needs to be done and can be used as a planning tool for sequencing the work. In contrast, a traditional SRS addresses only the issue of what is to be done on the project.

There is no attempt with an SRS to write requirements that can be implemented within a sprint or that are prioritized. Writing independent requirements is a minor goal at best, as shown by the hierarchical organization of most SRS documents, with their enumerated requirements such as 1.0, 1.1, 1.1.1, and so on.

These are not problems when an SRS is evaluated purely as a requirements document. But when the items within an SRS will also be used as product backlog items and prioritized, it creates problems.

With an SRS, it is often impossible for a team to develop requirement 1.1.1 without concurrently developing 1.1.2 and 1.1.5. These dependencies make it not as easy as picking a story at a time from a well-crafted product backlog.

Prioritizing sub-items on an SRS is also difficult, as is identifying a subset of features that creates a minimum viable product.

A Software Requirements Specification is good at being a requirements specification. It’s good at saying what a system or product is to do. (Of course, it misses out on all the agile aspects of emergent requirements, collaboration, discovery, and so on. I’m assuming these will still happen.)

But an SRS is not good for planning, prioritizing and scheduling work. A product backlog is used for both of these purposes on an agile project.

My Advice

In general, I do not recommend taking the time to rewrite a perfectly fine SRS. Rewriting the SRS into user stories and a nice product backlog could address the problems I’ve outlined. But, it is not usually worth the time required to rewrite an SRS into user stories.

Someone would have to spend time doing this, and usually that person could spend their time more profitably. I would be especially reluctant to rewrite an SRS if other teammates would be stalled in starting their own work while waiting for the rewritten product backlog.

A ScrumMaster or someone on the team will have to find ways of tracking progress against the SRS and making sure requirements within it don’t fall through the cracks. Usually enlisting help from QA in validating that everything in an SRS is done or listed in the product backlog is a smart move.

One additional important strategy would be educating those involved in creating SRS documents to consider doing so in a more agile-friendly manner for future projects. If you can do this, you’ll help your next project avoid the challenges created by a mismatch between agile and starting with an SRS document.

What Do You Think?

Please join the discussion and share your thoughts and experiences below. Have you worked on an agile project that started with a traditional SRS? How did it go? Would it have been different if the SRS had been rewritten as a more agile product backlog?

Thu, 01/01/1970 - 01:00