Related Content
 |
Take the High Road When Creating Product Roadmaps One of the mistakes made when crafting a product roadmap is building a roadmap that schedules all the features and functions you plan to build. That’s taking the low road. You want conversations with customers to be focused on the problems people solve with your product. That's taking the high road. |
|
 |
Why the Demand for Usability Will Continue to Grow Usability is an important aspect of any software system. It is often a driving factor in the popularity of software today. Yet, usability is only just in its infancy in terms of the importance it will play in future software systems. |
|
 |
Gamification Can Work—If Done Right Gamification is about applying game-design thinking to non-game applications to make them more fun and engaging. Pamela Rentz profiles some gamification projects that are getting it done right, and she highlights some guidelines for making gamification projects successful. |
|
 |
When Does Choosing a Mediocre Technology Make Sense? The technology world is obsessed with the latest and greatest. This doesn't come as a surprise. After all, we're all about innovation and building something better today than we built yesterday. Are there times when choosing a mediocre option—or even the worst option—makes sense? |
|
 |
Time Management for Developers and Testers We all have the same amount of time—and in that way, we are all equal. However, some people are more productive than others. Brendan Quinn looks at various time management tips and tools and how they can help software developers and testers become more productive. |
|
 |
Business Analysts: Your Team Is Your Customer, Too The most important customers of business analysts are the team members that create the solution. Secondary customers of the business analysts are stakeholders, sponsors, and end-customers of the product. Scott Sehlhorst explains what it means to think about your team as your customer, too. |
|
 |
Making Executable Documentation a Reality with DSLs A domain specific language (DSL) allows a development team to code in a language that business understands. This makes the syntax readable by technical and non-technical individuals alike. If your project is suffering from the overhead of excessive documentation, increase your velocity with a DSL. |
|
 |
Validating Requirements with Given-When-Then When identifying requirements, it can be really tricky to develop a good understanding of how software should behave. Scott Sehlhorst looks at the Given-When-Then approach and how it allows teams to combine the benefits of incremental development with the benefits of getting it right the first time. |
