How do you know what to build of your customer wants a “secure solution with a good amount of flexibility and user friendliness”? You don’t! Force the customer to be more specific!

This video explores split testing as a way to not only increase revenue and conversion through simple, surface-level changes, but also to dig deeper in order to help guide a product’s roadmap by discovering which features customers really want and how much they’re willing to pay.

In this blog post, James Christie starts from the fact that perfect requirements don’t exist to discuss the idea that the quality of requirements is directly influenced by the time and money you invest in crafting them.

By now, we are all comfortable with the orthodoxy: the product owner discerns the needs of the customer and feeds them to developers in the form a prioritized backlog. Developers pull work from that backlog, always confident that they’re working on the highest-priority feature at the moment, and never having to worry about how those priorities are allocated. This system is simple, efficient, and has helped many teams function better than they used to. It’s also time for the system to die.

Telerik has announced the latest advancements to TeamPulse, its agile project management offering. With the latest release, Telerik focuses on integration, adaptability and ease-of-use by introducing a Git and GitHub® integration, new REST API and .NET SDK as well as personas to drive feature requirements.

Blueprint has announced that its software now features new and enhanced integration capabilities that enable deep bi-directional data synchronization with all leading Agile Application Lifecycle Management (ALM) solutions. The new integrations are facilitated through a partnership with OpsHub, the leading provider of ALM integration and migration solutions.

In this blog post, By Scott Sehlhorst starts with a simple fact: if there is a lot of discussions on how to write requirements, there is not so much material on why to write requirements. His advice is that you should start by thinking about why you write requirements before you decide how to write your requirements.