A press release with Scrum — a practical guide to agile process design in business projects

To become more agile, all comes down to the correct process definition. What scrum shows us is, that it’s not a question of the individual’s mindset rather than of the process design.

However, what does Scrum mean in business projects, which have nothing to do with software development?

Let’s use a press release as an example of how you can use Scrum in “normal” projects. A warning for all Scrum enthusiast: On purpose, this is an overview and simplified breakdown and not a deep dive into the method.

That’s how you benefit from agile processes

1. Changes/Feedback are accepted easier by your team
   Your team doesn’t deliver a first draft or an early version. Nothing they consider as done; only the next “User Story” one small piece of the whole picture. They aren’t invested that much. Therefore they accept change requests easier.
2. You have a better knowledge of what your team is working on
   In Scrum, you start your day with a daily stand up — 2 minutes, 5 minutes not more. Everyone tells you about the tasks he or she will resolve today. The quick briefing is more satisfying than just having a ticket in progress, as in conventional PM methods.
3. You have something from start
   Speaking in IT terms, you have a working application from the start.
   A significant advantage of Scrum. The thing you have at the start isn’t much, isn’t everything but it’s still more than a fragment.

Step 1: Break it down

In Scrum, you break everything down into User Stories. More than tasks, it’s a description of the goal, of the bigger picture. That means you are forced to give your team the whole picture (this isn’t unusual in business projects but can be very uncommon in IT projects).

We break our press release down in 3 user stories:

• Write the title and the header
• Write the body
• Find the right pictures

Step 2: Work on the user stories one by one

Now the Scrum routine starts.

• Brief the one responsible (a single person or a team) for the story, in the so-called planning meeting. Explain the user story, ensure that he understands it. After that, he commits himself to a time of delivering. This time span is called sprint.
• Stay in touch with the team on a daily base. These so-called dailies are short meetings in the morning. You get informed on what your team is working on (in detail) and if they need anything to resolve possible blockers.
• Receive the results. At the end of each sprint, the results are presented to you. This meeting is called Demo and your chance to accept the user story or demand changes.

Again, this is just a brief overview; there are a lot of principals and formalities as well as roles in Scrum. There are plenty of resources out there about those details.

I hope you see the big difference between the usual project approaches and the advantages of Scrum. First, it may seem much more costly, but in the end, it’s a real time saver. You always know where your team is heading and you can interfere early.

Try it out.