3 Things Every Product Manager Should Know

May 17, 2011
Wikipedia "W" Award

Image via Wikipedia

Someone asked me recently how they could determine if their product manager was doing a good job or not.

I think this is always a tricky question.  There are lots of statistics that you can use — number of new customers, percentage of retained customers, revenue, revenue versus development cost, etc. — but some of these require information that may not exist.  For example, if your company hasn’t shipped your first product yet, you can’t really determine the number of new customers or the amount of revenue.

And sometimes, you simply want a quick and dirty way to reassure yourself that your product manager is doing a good job — that they are the “winner” you hope that they are.

So I suggest that a product manager needs to know the following three things.  If they do, then they are likely doing a good job.  If not, then something needs to change…

1.  What key business problems do your target customers have?

The product manager must know who your target customers are, some of the problems that they have, and which of those business problems the customers consider to be “key” or important.

Customers (and potential customers) will always have numerous problems — but only some of them are worth solving.  Some are simply irritants that your customers have decided to live with.   Others are so overwhelming that your customers don’t have the will (or money) to attempt to solve them.

Thus, “key business problems” have 2 characteristics:

  • Your customers want to solve them, and
  • Your customers believe your product can provide at least a partial solution.

These are the problems that a good product manager will understand thoroughly and can describe clearly whenever asked.

Say you’re talking to an e-commerce prospective customer whose web site is getting too many complaints from consumers trying to purchase products.  As a result, their revenue is declining and their support call center is overwhelmed.

If you were to talk to them, they might describe their situation like this:

  1. Consumer complaints are increasing,
  2. Sales revenue is decreasing
  3. Support call times are increasing (because they have to deal with irate consumers)
  4. Ad revenue is decreasing (due to reduced click-through rates)

But all of these complaints could be symptoms of a single “key business problem” — that the time required to purchase a product through their e-commerce website is taking far too long.

A good product manager will know what the “key business problems” are and will be able to tell the difference between “symptoms” and “problems”.

2.  How is your product approaching these key business problems?

OK, you have your list of key business problems from your target customers.  And you have your product which you hope to sell (or are selling) to these customers.  Before any customer gives you some of their hard-earned money, they will want to understand how your product makes their life better by solving one or more of their key problems.

They don’t want (or need) the gory details right away — they just want to understand the approach that your product is taking and be comfortable with the limitations (or risks) associated with using your product.

Consider our example e-commerce prospective customer…  Their problems could be due to traffic delays with their ad provider, network bandwidth limitations from their ISP, performance issues in their application, the number (and quality) of the images that they display for each product, the performance of their credit card processing partner, etc, etc, etc.

Perhaps your product collects statistics by monitoring each component’s performance.  Or perhaps you add a hardware device to a customer’s network to monitor communication between servers.  Or perhaps you monitor the application’s performance using simulated web browser client sessions.

Any of these approaches could diagnose the problem(s) with this prospective customer’s e-commerce system — but each approach also has potential limitations and/or risks.

A good product manager will understand how your product is intended to solve one or more key problems, be comfortable articulating your solution approach to a wide variety of audiences, and be well-versed in handling objections about the limitations and/or risks of your product’s approach.

3.  How well (or poorly) does your product solve these key business problems?

Once you present your product concept to a potential customer, you will have some feedback on how well (or poorly) they think your product will solve their key business problems.  You will get more information each time you interact with a potential customer and even more information when a customer starts using your product.   Once you have collected information from a dozen or so customers and potential customers — some patterns will begin to emerge.

Did you identify your target customers and their key problems correctly?  Do you actually understand their key problems and why they are important to your target customers?  Does the approach of your product appeal to them?  Do they think that your product can actually help them?  How well does your product actually help them?

If your product manager knows the answers to these questions — and a bunch more just like them — then your product manager can easily tell you how well (or poorly) your product solves the key business problems of your target customers.

Or put differently, a good product manager can tell you whether your product is likely to be successful or not in the marketplace and where your product needs to be improved to attract a larger share of the market.

Conclusion

Evaluating a product manager is not easy because there are a myriad of company cultures, product types, personalities, and business situations in this world and no two situations (or product managers) are identical.

However, a good product manager will always know:

  • What customer problems their product is attempting to solve,
  • How the product intends to solve these problems, and
  • How well (or poorly) the product solves these problems.

In addition, a good product manager knows that customer situations continue to evolve — so they will maintain contact with current and prospective customers, anticipate future needs, and provide timely product solutions — instead of reacting after the fact with something that doesn’t match what their customers need, want, or will buy.

Advertisements

How is Agile like a frog in a pot of water?

April 29, 2011
Frog example

Image via Wikipedia

Remember the old tale about the frog and a pot of water?   In essence, if you put a frog into a pot of very hot water, it will immediately jump out.   However, if you put a frog into a pot of cold water and gradually heat it, the frog will allow itself to be cooked to death.

Not to worry — I have never done either of these and I don’t suggest that you do so either.

However, there are lessons from this tale that I believe apply to the Agile development methodology…

I believe that a “successful product” must provide a valuable resolution to one or more needs from your target market.  Otherwise, nobody will buy it.  So when I talk to other Agile practitioners, I am amazed at how little thought they give to getting accurate and reliable feedback from their market.  Many of them make one (or both) of the following mistakes:

Product Owners Focused Solely on Development

The product owners of some companies spend so much time with Development that they quickly lose touch with their market.  Or even worse, allow the product direction to be set by the 1 or 2 customers that they have time to talk to.   Sure, they could talk to a number of customers via email, Skype, Twitter, etc — but you will only get answers to questions that you ask or reactions to significant positive (or negative) aspects of your products.  You may never know that some function takes twice as many clicks to complete as it should or that users are constantly using other tools to compensate for functional gaps in your product.

To know what your customers really “need”, you have to talk to enough of them so that you understand the difference between what a few customers say they want and what your product needs to provide to satisfy your target market.

Note:  If you’re interested in how to do this, consider this article written by Steve Johnson, Luke Hohmann and Rich Mironov  published by Pragmatic Marketing,

Developers Gone Native

Some companies encourage Developers to engage with customers so that they can get first-hand knowledge of what the customers need.    They carefully select the Developers for this task, because some are simply better suited for this type of interaction than others.

However, there are at least 2 problems with this approach…

  1. The Developers can’t spend a lot of time talking to customers — because they are typically senior people who need to be contributing to the product, and
  2. The Developers usually do not have the skills / experience to identify what each customer really “needs” (as opposed to what they say they want) and to synthesize the requirements for the product’s target market from feedback from only a few customers.

As a result, the Developers often focus on providing the capabilities that the customers they have met say they need — almost as if they were working directly (or “natively”) for those customers — instead of providing capabilities that benefit the majority of the product’s target market.

The Frog and the Water

If done right, Agile allows you to get rapid feedback from your market to keep you on course toward creating a successful product.  But your product can “go off the rails” just as easily with Agile if you don’t understand how to obtain and utilize customer feedback.

Waterfall is like the pot of hot water — it provides dramatic evidence of how well (or poorly) your product matches the needs of the market.

Agile is like the pot of cold water — and each iteration increases the temperature of the water in the pot a bit.   So if you do not have good people who are experienced in obtaining and understanding market feedback — you could, like the frog, sit in your pot until it is too late.

What Should You Do?

I believe that each product development team should consist of people who are highly qualified to do their specific jobs.  I look for teams where well-trained engineers are developing a product that is being tested by experienced QA personnel.  I’m not fond of teams where “everyone does everything” — because not everyone can be an expert at everything.

Likewise, your development team should include someone who understands the “art” of obtaining feedback from current (and potential) customers and synthesizing that into prioritized product requirements.  Whether you call this person a “product owner”, “product manager” or something else is up to you.   But they need to spend time at least 25% of their time with your current (and potential) customers.  Otherwise, they will quickly lose touch with what your target market needs and will have to rely on their own opinions, guesses, and/or hopes.

Creating a software product is very expensive and you can’t afford to make very many mistakes, because in many cases your competition is only “one click away” for a current (or potential) customer.  So avoid the temptation to ask developers to do this job “in their spare time” and get yourself a good product manager who can do this job “full time”.


The 7 Principles of Software Product Management

April 6, 2011
A stool with adjustable height.

Image via Wikipedia

As software product managers, we are constantly analyzing data:  needs from customers, revenue from sales, win/loss reports, development plans and costs, feature specifications, evaluations of competitors, etc.

As we process all of this information, an effective product manager should be guided by 7 key principles, divided into 2 key categories, as follows:

Product Planning

Effective software product planning requires you to balance the following 3 key principles:

  1. Customers — Your customers (or potential customers) represent the needs that your product should be fulfilling and the revenue that your company expects to receive by providing them with a suitable product (or service).
  2. Product (or Service) — This is the mechanism (or method) that your company uses to provide value to your customers.   If your product doesn’t fulfill most of their needs, then they will go elsewhere and buy something else.
  3. Product Team — This is the staff that your company employs (either directly or indirectly) to create and deliver your product (or service).  If your team doesn’t provide a suitable product, your customers will not be satisfied.  And if your team doesn’t know what your customers need, or understand how much your customers appreciate your products, then they will be unlikely (or perhaps, unable) to create a suitable product.

These three principles can be thought of as the 3 legs of a stool, with your company resting on the seat.  As a product manager, you must constantly balance these 3 elements.   If you over-emphasize (or under-emphasize) one of these principles, then your company will fail.   Just like a stool will fall over if one of its legs is overly long or short.

Product Creation

Creating a software product (or service) is an iterative process, whether you are using Waterfall, Agile, or some other development methodology.  In all cases, your product (or service) is provided to your customers in one or more releases.   As a product manager, you must balance 4 additional key principles for each of these releases, as follows:

  1. Content — Each release contains a certain amount of content.  A number of bugs that have been fixed, a number of new features that have been developed, and perhaps one or more changes to the infrastructure of your product.
  2. Resources — Each release is created (and tested) by a specified group of people; usually those who have the knowledge necessary to effectively and efficiently do the work.
  3. Schedule — Each release is delivered (or at least, planned to be delivered) according to a specific schedule, based upon the amount of work that needs to be done and the approximate date when the finished release needs to be completed.
  4. Quality — Each release must achieve a certain level of quality to ensure that it is suitable to used by the desired customers to accomplish its stated purpose.

As a product manager, you must also balance these 4 principles so that each release helps increase the value that your product provides to your customer.

However, in most situations you don’t have nearly as much flexibility.    Each product release must achieve a certain minimal level of quality, and while it is desirable to achieve a much greater quality, it is rare that this happens.   And although it may be tempting to increase the content you can complete within a given timeframe by adding resources — this rarely works — as explained in  The Mythical Man Month.

Thus, you typically have to manage trade-offs between the content that each release includes and the date (or schedule) when it will be available.

Conclusions

Product management is all about balance.   You need to  effectively (and consistently) balance the 4 principles that define the creation of each product release and also balance the 3 principles that govern your product planning.

If you do this well, your customers, company, product, and your team will all benefit — and you will be able to sleep well at night feeling good about yourself — which is always a good thing.


Creating a contract for work done in an Agile environment

March 5, 2011
3 Iterations of Agile Development Framework

Image via Wikipedia

I’ve been talking to some colleagues lately who do consulting work, usually software development, for various companies.  Typically, they have been engaged by clients in traditional (or “waterfall”) projects, where they provided specific functionality that met specific quality criteria and had to be completed according to a specific schedule.   In return, they received an agreed-upon compensation.

These types of projects were relatively easy to estimate, bid, and negotiate with clients because all of the deliverables (content, schedule, and quality) were fixed in advance.

However, as more and more of their clients are wanting to have their projects developed using Agile, their traditional types of software contracts simply don’t work.

One of the fundamental aspects of Agile is that a small amount of the work in the total project is performed in a short time period, or sprint.  Each sprint lasts 2-4 weeks (on average) and the content for each subsequent sprint is identified in part by determining how well (or poorly) the already completed work meets the customers’ needs.  Thus, if a certain bit of functionality is developed in a given sprint, it could be modified significantly (or even re-done completely) in one or more subsequent sprints.

Thus, it is possible for a client to spend so much time refining and “polishing” work that has already been completed, that the overall duration of the project extends far, far beyond the original target completion date.    And as you can appreciate, the client doesn’t typically offer additional compensation to the people doing the work — arguing that the work should have been done “properly” in the first place — although it’s not clear how anyone could have done the work “properly” when the client didn’t know what they wanted in the first place.

It’s clear that the Agile development methodology is not going away — its advantages are too great to ignore.   So we need to modify the contract language we use to engage consultants accordingly.  Otherwise, consultants will either go broke attempting to provide the “free work” required by ever-changing functionality or will simply refuse to perform work in an Agile environment.

Here’s what I think…

In a software project there are only 4 variables — (1) the content being provided, (2) the schedule for the delivery (or deliveries), (3) the quality that is achieved, and (4) the resources that are deployed to do the work.   (Note:  Cost is an attribute of a project, not a variable.)

Thus, if a contract is going to embrace Agile development concepts where (a) the project’s content is allowed to change frequently to accommodate re-work, (2) the project has to achieve a specified level of quality, and (c) the project’s schedule must adjust to accommodate any re-work — the ONLY variable left is “the resources that are deployed to do the work”.    And since every resource contributes a certain amount of effort to the project — the contract must specify a certain amount of work (or “hours”) that the client is paying the consultant (or consulting organization) to perform.

This type of contract is not especially attractive to a consultant because it is too transparent.   A potential client can easily identify the hourly rate for different consultants and compare them with rates from others.  Thus, “premium” consultants (or consulting organizations) must provide additional justification on the “value” of their services — which is often not easy to provide in a convincing manner, especially in difficult economic times.

In some cases, clients are also not as comfortable with this type of contract — because it makes it difficult to justify continuing to do business with a long-established consultant (or consulting organization) when it becomes obvious that their hourly rates are significantly more than those of other potential providers.

However, as more and more contracts are written with Agile development in mind — consultants and their clients will become more comfortable — just as development teams have increasingly embraced Agile in recent years.

So, if you are a consultant I urge you to develop a contract where you get paid on an hourly basis soon, so that you are well positioned to bid opportunities for Agile projects.  And if you are a company that employs consultants for Agile projects, I encourage you to request contracts with hourly labor rates, so that you can optimize the quality of your projects.


The 2 Most Important Words for a Product Manager

January 27, 2011

I’ve been reading the “42 Rules of Product Management” recently which is an excellent book consisting of articles contributed by a number of well-respected product management professionals.  My only problem with this book is that I can’t remember 42 of anything for very long.   So with this in mind, I propose the 2 most important words for a product manager to live by — “Why” and “No”.

“Why”

You’re siting with a customer and they describe a feature, perhaps one that seems completely inconsistent with your product plans.  You can dismiss this idea or even dismiss the customer.  But you first need to know Why they thought this idea was important.   Time is precious to customers also, so they are unlikely to waste their time describing something they want unless it is important.  So ask them “Why is this important”? and make sure you listen (and understand) what they are saying.

Or perhaps you’re looking at your visitor count, promotion results, and sales numbers for your storefront during the last quarter.  The results in February are stronger than expected, especially since you didn’t run any special promotions that month.  You need to know “why this happened.”   Perhaps your promotions are not compelling (so it doesn’t matter if you ran any or not), perhaps your email newsletters are being interpreted as SPAM.  Perhaps your products are most interesting to Valentine’s Day shoppers.   You can’t afford to guess — so you need to know “Why”.

“No”

As you listen to more and more of your customers (and prospects), one thing will become very clear — you can’t please every one of them every time.  That’s why the “80/20” rule exists in the first place.  So you have three choices when a customer asks for something that you have no intention of providing them:

  1. String them along — promise them that you’ll look at it “soon” or in the “next release”.  But after a couple of promises like this, your credibility with this customer will be gone and they won’t want to talk to you in the future.
  2. Lie to them — Promise them that you’ll include their feature and then fail to do so.  Of course, this also ruins your credibility with this customer and they will not trust you in the future.
  3. Tell them “no” — Tell them the truth; that there is not enough demand for their feature from other customers.  They may object initially, but eventually they will appreciate your honesty, because it gives them options.   They can appeal to your management, provide additional information to justify their request, provide funding for you to do it as a “customization”, coordinate requests for this feature with other  customers, or decide to live without it.

Nobody said it was easy to tell a very important, strategic customer “no” — but you must have the courage to do what is right — for the benefit of your customers, your product, your company, and your team.

An Example:

Here’s what happened to me a while ago with a large automobile company.  This company had been using our enterprise software for quite a while in a test environment and always provided good feedback — lists and lists of highly detailed enhancement requests.  But they never made much progress in deploying our software in production, so it was hard to prioritize their enhancement requests over those from other production customers. One of their enhancement requests was “allow longer passwords”.  It had a high priority, but so did many of their other requests.   And since our product was built around a 8-character password — we didn’t see any point to expending the effort to change this.  In essence, we said “no”.

One day during a visit to their facility, we discussed their very long list of enhancements.  When the discussion reached the “longer password” item, their IT Manager explained that all of their other corporate systems required a password of 10 characters — so they could not even suggest adoption of our software because it didn’t meet their security guidelines.  Once we understood the “why” of their enhancement request, it became a high priority for us and the very next revision of our software allowed passwords of up to 16 characters.   Our customer deployed our software almost immediately and used it successfully in their business for quite a few years.  And in case you were wondering, they were never able to provide a written explanation of why they needed a longer password, because their internal security policies didn’t allow them to disclose this type of information in writing to anyone — for fear of compromising their other systems.

The Bottom Line

Learn to always ask “why” and be prepared to say “no” when it is appropriate.  But also be aware that a “no” can become a “yes” once you learn enough to understand “why”.


Does Agile development work for ALL software products?

November 2, 2010

I think most people involved in developing software have a reasonable understanding of what Agile / Scrum development is all about.  The general idea is to get customer feedback early and often so that you can adjust the finished product to something that is almost guaranteed to be what the customer wants.

The Scrum project management method. Part of t...

Image via Wikipedia

This is clearly a much better idea than the traditional, or waterfall, approach where you spend months figuring out what the customer wants, more months building it, and then hope (or pray) that the customer hasn’t changed their mind or that the market hasn’t moved while you were doing all the work.

And history is full of examples of products developed using the traditional way that didn’t get close to living up to their original market expectations because they were obsolete or out of touch with their market the day they were introduced.

However, when you listen to some Agile zealots talk — you will hear things like “there never was a product that couldn’t be developed using Agile”.   Frankly, this reminds me of “one size fits all” which anyone over the age of 5 knows is simply not true — especially in today’s market where every customer wants it “their way”.

So with your help, I would like to identify products (or situations) where Agile development may not be the best approach.  The goal is to avoid trying to force-fit Agile where it clearly won’t work and to identify how to adapt Agile concepts in other cases so that we can get the best possible product in every situation.

OK — I know this is ambitious and possibly not achievable.  But a journey of many miles begins with a single step.  So let’s get started by talking about some product types where Agile will have problems:

  1. Embedded Software — The software that runs all of the “electronic” modules in your car are a good example, including the ABS system, the throttle control system, and the fuel injection system.  Obviously, you can’t ship an interim version of this software to your customers and ask for their feedback — they wouldn’t know how to test it.   And imagine if the software had a bug, the car accelerated out of control and someone was injured or killed.   How would the manufacturer explain that it was only a “test” version of the software? (Hmmm, this sounds vaguely familiar for some reason…)   Lastly, it takes a long time to ship a product like this to a customer.  So even if you could get customer feedback, it would come so long after the development had been completed as to be nearly useless to the development team.
  2. Enterprise Software that Requires Customization — This is an idea that I described previously, so I will summarize.  Imagine that you provide a customer with software that takes them 6 months (or more) to customize and deploy, how will they ever be able to provide you with timely feedback?
  3. Real Mission Critical Systems — The software that monitors and manages the nuclear reactor in a power plant is a good example.  How could any software provider explain away an interim software release that allowed a catastrophe to occur because a feature wasn’t “finished”?    I mean before they lost everything in the inevitable flood of litigation.

There are only a few examples, but they seem to have a few things in common.  Perhaps Agile / Scrum development only works with products / situations without these characteristics:

  • No Timely Feedback — It is not possible to obtain feedback from the customer / end user sufficiently fast enough for the Development team to review and incorporate it into the product.
  • No Ability to Fail — It is not possible for the product to fail, due to a feature that is incomplete, incorrectly designed, or improperly implemented, without subjecting the customer / end user to unacceptably high risks.
  • Not a Standard Product — It it not possible for customers to effectively use a “standard” version of the product.  Every version must be customized before it can be used (or tested) by a customer which makes it very difficult to detect whether a failure is in the product or a customization.

I’m sure I’ve only scratched the surface, so feel free to add your comments.

And next time, we’ll look at a few ideas for using Agile Development practices for products which have one or more of these characteristics…


Documenting Requirements — the Tools you will need to be successful.

November 2, 2010

I wrote previously about an approach that I have used to manage requirements.  Subsequently, I have been asked to elaborate on the tools and rationale, so here goes…

As previously discussed, “requirements” consist of a wide variety of inputs from numerous internal and external stake holders.   Yet all requirements suffer from 2 problems — (1) It is impossible to address all of your open requirements in a given software release, and (2) things change.

So, that very carefully defined requirement from that key customer that was documented in year 1 may be significantly different from what that same customer needs in year 2 (or year 3).  You obviously don’t want to spend time developing something that doesn’t meet a business need and you also don’t want to lose any of the knowledge about that requirement that you have collected from this customer (and others).  Lastly, if you are going to reconnect with a customer to review the details of a particular business need — you MUST have a good understanding of what they have said before — or they will dismiss you as a waste of their time — which is not helpful on many fronts.

In other words for every requirement, you need some method to gather, track, and maintain its “definition” and the features that you will need to address it over time.  A document management system (such as Alfresco) is an ideal tool for this purpose.

You may ask — “but why not use a source code control system like Subversion or CVS?”   The simple answer is “they are not the right tools”.   Source code control systems are designed to help multiple people work on source code files that often overlap with one another.   Thus, these systems have sophisticated tools for identifying the differences between two versions of the same source code file and allowing them to be merged together.  In my experience, these tools do not work with documents — especially Microsoft Word documents — and can even corrupt the formatting and content in some cases.  In addition, source code control systems typically require each user to maintain a local content repository that must be synchronized on a regular basis to ensure that each user is always looking at the most current copy of a document — which is counter-intuitive, at best, for most non-Engineering personnel.

By contrast, a document management system is designed for editing, sharing, and managing “documents”.  It uses a simple check-in and check-out model that allows users to view any accessible document but requires all updates to be done using an exclusive write approach.  A document management system also provides tools for managing the maturity of each document so that preliminary feature ideas can be shared with some people and more mature feature definitions can be shared with others.   (Have you ever had a situation where a very early version of an idea was sold to a new customer by an overly aggressive sales person?  If so, then you should appreciate the ability to control when requirement and feature information is shared with different audiences.)

In other words, a document management system is the best tool for “managing documents” whereas a source code control system is the best tool for “managing source code”.  (Apologies if this seems redundant.)

You also need a method to plan a software release that will (hopefully) include numerous features that each address one or more requirements.  You need a method to select which features will be included in each release and a way to obtain estimates from Engineering on what it will cost to develop each feature.  You also need the ability to iterate the definition of each release numerous times — adding or subtracting different features — trying to get the “perfect” balance between features, schedule, and Engineering capacity.

You also need to capture all of the assumptions and dependencies that Engineering identified while creating their estimates for 2 very important reasons:  (a) Engineering spent time (and money) creating these estimates and if a particular requirement isn’t addressed now, it may be later.  You don’t want to pay twice for the same thing. (b) If you know how each estimate was derived, you are much more able to verify previous estimates or anticipate problems with current estimates, based upon$ its assumptions and dependencies — even if your Engineering personnel change over time.

You could plan each software release using a spreadsheet — but why would you want to?   Do you really want to continually update the spreadsheet, circulate it to numerous internal people, and then consolidate all of their inputs?   And even if you want to operate this way — do you really have the time?  Or are you assuming that you will get each release planned perfectly the first time?

This is where an issue tracking system (such as Jira) can (help) keep you sane.  You can use a field (such as “Specification”) to include a link to the relevant requirements document within your document management system.  You can use another field (such as “Target Release”) to designate the features that you want Engineering to review and have them include their estimates and assumptions in other fields — based upon the information on the feature and its underlying requirement(s) maintained in your document management system.  So when you generate a report (or Excel export) for a given software release — you will be able to immediately determine whether you have under or over defined the release based upon your Engineering capacity.

You are almost done — all you need now is a “plan” for this release.   If you are using the waterfall method, I suggest creating a project plan with Microsoft Project using the feature, dependencies, and estimate information from your issue tracker.   Update it regularly (I suggest weekly) and provide copies to all team members.  (I suggest using a PDF print driver so that you can easily share the project plan with everyone without requiring them to have access to Microsoft Project.)

If you are using Agile, I suggest using the GreenHopper plug-in for Jira — or something similar — to plan each sprint.

That’s all for now.  I hope this has been helpful.   As always, comments or questions are welcome.


%d bloggers like this: