It can be as simple as a bookmarking solution, or a cloud file storage program, or something as spectacular as Google Maps. It’s software that’s just so well done you might’ve wondered what you did before.

But building great software is more than just writing code that doesn’t crash. It’s more than making a good user interface and experience that doesn’t get in the way and makes everything simple and easy to find. Building great software is about making sure you’re building the right software and solving the real problem. These elements coming together are what make great software.

So that’s what we aim to do for our customers when we build software. We’re trying to create an experience that inspires someone to say, “Wow, that’s pretty great.” That’s Software Joy.

If the answer is “yes”, then there are several advantages to creating separate stories. Remember, a team’s capacity is measured in story points, not number of stories. This means that breaking stories up doesn’t mean you’re increasing scope, you’re just allowing for more granular prioritization, which ultimately means delivering more value in the time/budget you have available.

If you think of a user story as an encapsulation of business objectives, which are described by acceptance criteria, then there are at least three characteristics you can examine to help decide whether or not those objectives can (or must) be delivered separately:

1. Dependencies. Do the objectives of a story share common dependencies? Will the dependencies be available at the same time? If different aspects of the story depend on different outside resources, and those resources may not become available at the same time then the story should be broken into pieces by common dependencies. This way, smaller portions of the original story can be worked on independently of the rest, which may not be unblocked until a future iteration.
2. Priority. Are there different priorities represented within the story? If one aspect of a story is a must have, and another part you could do without, break it up so that the two stories can be sized and committed to separately. This is extremely important because any time spent delivering functionality which is not of the highest priority at that time means that in a given time window you will not get the most possible value delivered.
3. Size. Is the story too large to be described in detail? Does it have a clear, cohesive set of objectives? Assuming all the elements of a story have common dependencies and priority, take a look at the size of the story. The larger a story is, the less accurate the estimate is likely to be. This is because large stories rarely have the same level of detail as smaller stories, which makes them harder for a development team to estimate, as there are more unknowns. Break the story up into smaller pieces and focus on providing as much detail as possible for the smaller pieces, highest priority pieces.

Ultimately, there’s very little to lose by breaking a story into smaller pieces, and potentially, a lot to gain. If you’re asking yourself if a story should be divided, it highly likely you already know the answer to be yes.

Sure, Agile is a really good development philosophy—as far as we know, it’s the best one—but it’s no silver bullet. In fact, when it comes to software projects, there’s no such thing.

On the bright side, silver bullets do work (as advertised) on werewolves, so you still have a chance of surviving a werewolf apocalypse. But what about your software project?

If you want your software project to be a success, you’ll need to be vigilant. Here are some warning signs that your development team might be infiltrated by werewolves:

1. Productivity drops off when there’s a full moon and several members of the team suddenly disappear. Remaining team members pick their teeth a lot. Coincidence? Maybe. Did you thoroughly check the firm’s references?
2. There are unexplained scratch marks on the project board. Could be werewolves—or a sign of frustration from an inexperienced Agile development team. Again, did you check references?
3. Team members all have the same ringtone: a wolf howl. Aah-ooooooooh! Not good…
4. The software doesn’t work but the loading screen has a well-rendered image of a full moon, with the caption “You’re next”. This could indicate werewolves but it could also be a ruse to divert your attention from the poor software. Investigate.
5. Your designated Product Owner complains to you about all the whining, barking, and growling that she hears in team meetings.

Whether you find werewolves on your team, or just developers with bad people skills, tread lightly. Either way, your software is in trouble.

Choose a team of experienced, hardworking professionals to develop your software and save your silver bullets—you’re going to need them. The werewolves are coming…

But what about your boss? What if your boss wants to save a few dollars up front by purchasing a very limited contact management system that you expect to outgrow in a year or two?

Here are 5 tactics you can use to convince your boss to buy a flexible CRM:

1. Map your organization’s growth curve to CRM functionality. Prepare a timetable showing some attainable organizational goals for the sales and marketing department over the next few years. Compare those goals with the feature set of the software that your boss wants and with the flexible CRM that you’d like to buy. Walk your boss through the comparison and show exactly where you’ll hit the ceiling unless you get a flexible CRM.
2. Collect CRM customer reviews. Get online and find out what people are saying about the software your boss wants to buy and the flexible CRM that you prefer. Build a portfolio of credible product reviews and present them—the good ones and the bad ones—to your boss in a fair and balanced way.
3. Talk to actual users. Find some organizations (similar to your own) that use the software you’re considering and connect with people who have firsthand experience. Be sure to ask questions like, “If you had a chance to go back and change things, would you choose a different product? Why/Why not?” and “Do you expect to outgrow your system? If so, when? What will the switching costs be?”
4. Demo both systems for your boss. Arrange for a free trial of the software that your boss wants and the flexible CRM that you’d like to get, then set up two computers side by side and compare the ease of use/functionality of both systems.
5. Identify areas where you might need to customize. Compare your goals and processes to the features included in the software under consideration. Where does standard functionality fall short in each system? To what degree can each system be customized? Is it easy to do? What are the costs? Can the CRM system extend or integrate with other areas such as marketing automation, inventory and financials, ensuring clean end-to-end business processes?

With a little coaxing, hopefully your boss will agree to a flexible CRM that allows you to buy only what you need, with the option of adding features and capacity as needed.

If you’d like to chat with us about CRMs, or if you’re looking for advice on CRM products, you’re welcome to contact us and set up an appointment. Good luck!

In this third and final installment, our Really Serious Person takes a look at Architech white papers related to custom software and marketing automation.

So, without further ado…

Crush Your Competitors with Custom Software

Who should read it: Read this paper if you want to learn how custom software can give your company a competitive advantage.

What’s in it: We explain why custom software is now an affordable option for organizations of all sizes and we look at two ways that IT can undermine your competitiveness. We then show how custom software can give your business a competitive advantage, we discuss the benefits of taking this approach, and we conclude by listing some characteristics of great custom software.

Key takeaways: You’ll learn why it often makes sense to use custom software instead of generic, off-the-shelf products.

In a nutshell: The advantages of using custom software.

Home Ice Advantage: Local Software has a Competitive Edge

Who should read it: If you’re thinking of outsourcing a software project to an offshore vendor, you should read this paper before making any firm decisions.

What’s in it: We briefly discuss the types of companies that do a lot of offshoring, as well as the kinds of software projects that typically get sent to offshore vendors. We then look at specific problems and risks associated with sending a software project to an offshore vendor. Finally, we discuss the benefits of partnering with a local software development firm.

Key takeaways: You’ll learn about some of the difficulties involved in sending a software project offshore.

In a nutshell: Why a local firm makes sense for design/development of complicated systems.

Serving! One Customer at a Time: How to Win with Marketing Automation

Who should read it: If you want to know how technology can help you find and nurture more high-quality leads than ever before, read this paper.

What’s in it: We look at how the Internet has fundamentally changed buying patterns and we discuss 3 reasons why mass marketing is no longer effective. We then introduce the 3 elements of a one-to-one marketing automation strategy: search/social media, website, and direct communication. We examine the tactics that online marketers use to generate quality leads and nurture them until they can be handed off to the sales department. We conclude by reviewing the benefits of marketing automation.

Key takeaways: You’ll learn why marketing automation is now essential to business success. You’ll understand how the new marketing ecosystem works.

In a nutshell: Marketing automation 101.

Hit the Target with E-mail Marketing: One-to-One Best Practices

Who should read it: Read this white paper if you’re preparing to jump into e-mail marketing.

What’s in it: We review the principal elements of a marketing automation strategy and explain where one-to-one e-mail marketing fits in. We talk about spam filters and discuss the drawbacks of batch and blast e-mail campaigns. Then we review e-mail marketing best practices in three areas: deliverability, design, and segmentation. Finally, we describe what you should look for in an e-mail service provider (ESP).

Key takeaways: You’ll learn how to make your e-mail messages more effective and how to avoid some nasty e-mail marketing pitfalls.

In a nutshell: E-mail marketing best practices.

We hope that you’re enjoying the white papers in our library. If you have a topic that you’d like us to address in a white paper, feel free to contact us with your suggestion.

Likewise, if you have questions about custom software, marketing automation, proper software engineering, Agile/Lean, or any other aspect of software development, please contact us.

We promise to be really serious…most of the time.