In the last articles we talked about how you can get a good overview of the tasks to be done by defining your goals ( link ), creating a rough plan ( link ) and conducting a workshop ( link ). This article is now about how to summarize your many ideas and get them into a detailed plan.
Before we start with the detailed planning, we would like to introduce you to a concept from Lean Startup, the MVP (“Minimum Viable Product”) or the just-as-useful product. This refers to a product that has a minimal range of functions, but already offers an additional value to the user.
It serves to quickly realize one’s own ideas and to reflect the user’s needs. Keep this in mind, to realize a minimal functional scope, when it comes to the derivation of a detailed planning in the following.
What we describe in this article is our approach and our experience with it. We don’t start with the classic methods and pure doctrine, maybe more about that in later articles. Here you should learn what works well for us and in the best case, you can use many of the approaches for yourself or you adapt them to your needs.
Agile is often mistakenly equated with not planning. Compared to the classic waterfall, it may seem that way. However, the onion principle ( link ) is not only invalid because someone is now working Agile. For us, agile means being able to adapt quickly to changes, to communicate a lot and to evaluate what has been achieved self-critically.
Waterfall in the classic sense means that the project steps are carried out linearly, i.e. one after the other. Analogous to a process, only when one step has been completed the next one follows. There is no iteration.
The project plan is thus created once and after a certain time all project phases are passed and the project is finished. Changes are only reacted to at the end, with a new project plan. You can think of it as a train running on a track. Again, this is the classic view and there are of course variations. In contrast, agile means reacting to changes. So if you don’t take the train but the car, you can flexibly adjust your route and, for example, avoid a traffic jam, in contrast to the train that can’t avoid a blocked track.
Quite clearly, no! The various methods are tools for solving problems. As diverse as the problems can be, as diverse solutions are needed. If your goal and your way to reach the goal are uncertain, then an Agile method may be better. If you know exactly who has to do what and when, and the aim is to achieve the project goal quickly and predictably, you might use a method based on the waterfall principle. Try not to strictly divide the methods, but rather put together the principles that fit your requirements. But now let’s start with the detailed planning.
In the last step, you have derived many possible and useful features from both the brainstorming ( link ) and the eventstorming ( link ). Now think about which ones are absolutely necessary for your idea. In order to realize this, it is helpful to simplify your goal so far that the core idea just remains intact. For example, we want to make it easier for people to find open source projects quickly and easily. The core idea is to search and find open source projects. In the simplest case this is a search bar on a website ( link ). Now categorize your features according to which:
It is clear that you have to implement point one first, without that there is no product. For point two, it is important that you pick the one advantage over other products that you think will benefit your users the most. To do this, look at other products, preferably use them. Read user reviews and forum discussions. Try to get a fairly accurate picture of what might appeal to your future users. All other advantages from point 2 you can put in point 3 and save for later. Once you have decided on the minimum set of features, then you can start planning those features.
How would you go about moving multiple cabinets from one room to another? If you’re on your own probably by clearing out the cabinets, disassembling, transporting, assembling and putting them back in, similar here. The big problem of moving the cabinets, which you can’t lift or push, to another room in one piece is futile. You have to portion the problem. Take a feature out of the intended feature set and ask yourself the question, how long will it take me to develop, test and get this feature operational. And what do you think? You probably can’t give a good estimate yet. This tells you that the task is still too big. Think about the steps you need. For example, if you want to build a garden house, think about what steps are needed. You may need to make a drawing, plan and buy materials, cut boards to size, and so on. At each step you try to estimate the effort again. If it is easy for you, then you have probably reached the right planning depth. The purpose of estimating effort is to help you visualize the work. To estimate how long an activity will take, you need to know what needs to be done.
At WeValCo, we simplify a bit at this point. Instead of a precise time estimate, we evaluate the effort according to previously defined criteria. For us, the following time units have worked well: a few hours, a few days, more than a week but less than two weeks (but for you, these classes can be quite different). Anything beyond two weeks we break up into more subtasks. It is also important that we don’t divide the whole functional scope into work packages already at the beginning.
In the first step we put the single functions in a logical order, if there is one. As an example, putting in the windows before one wall of the garden house is finished is not possible. So, for example, first assemble the wall, then finish the window, and then install the window in the wall. There does not always have to be this logical order and especially in software development many tasks can be processed in parallel. But also think about which areas should be developed before others. For example, to develop, implement and test functionality for a website, it would be good to create a test website in advance.
In the second step, we start to break down one of the functions into work packages, as described above. If the corresponding work packages already load us for the coming weeks, we finish the planning. If not, we take another function and break it down. For us it is sufficient to create work packages for the next 4-6 weeks. Keep in mind, the further into the future you plan, the more likely you are to adjust the planning again. The less you plan, the less correlations between the work packages you will notice and you may have to adjust the implementation. Try to define a well-suited planning horizon for yourself, you can adapt this individually and change it at any time.
If you have found a rough order of functions and worked out enough work packages, then you can actually start. But it makes sense to set a period of time, after which you look back and reflect on what you have accomplished. We do this in so-called sprints, which have a duration of 2 weeks. At the beginning of a sprint we determine who will work on which work packages. Each work package is in an effort class and each effort class has points. We assigned one point for the effort class “a few hours”, 7 points for “a few days” and 20 points for “between 1 week and 2”. Per 2 weeks sprint we manage about 20 – 25 points per person and accordingly everyone takes work packages at the beginning of a sprint. These points are individual, just like the effort classes, and you can try out for yourself which gradations suit you. At the end of a sprint, you can reflect on whether you have achieved your goals well or not. Also think about why something worked well or not so well. Are the work packages still too big or were you too optimistic about how many work packages you could accomplish in the timeframe you set? Iterate yourself to a system that suits you. Reflection at the end of a sprint is essential. Only through reflection will you become better at planning and more efficient at your work. Always ask yourself: “What went well and why?” and “What went badly and why?”. Be self-critical but also be proud of what you have achieved! Use your experience with the current sprint to plan the next sprint. If you were able to complete a work package well, then simply use the same effort estimate again for subsequent tasks with a similar scope. If it didn’t work out well, then adjust your planning the next time.
At the end of each sprint, we check whether there are still enough work packages planned and plan new ones if necessary. Then we fill the following sprint with work packages again and the cycle starts anew.
For tracking our tasks we use Kanban. On a Kanban board you can see, for example, which tasks you have planned for the current sprint, which are currently being worked on, which are finished and still need to be discussed with colleagues, and which are completely finished. You can find free Kanban solutions in our search ( link ).
We discuss the current progress of our tasks in short, daily meetings of a few minutes. This way, everyone keeps track of each other’s tasks and can quickly get feedback on any problems. Note, however, that it really remains a short exchange! Extensive discussions can be held afterwards and in smaller circles.
Mia, Peter and Zou have also worked out ideas about their feature set in recent articles ( link ). First, they would like to specify the functions that are really necessary and agree on one special feature. For a video chat, it definitely needs a video and audio transmission of at least two participants. One of the participants must be able to invite another and the other participant must be able to accept or decline the invitation. The three categorize all work packages related to this basic feature set as “absolutely necessary.” The three discuss the one outstanding function at length. Zou thinks a contact list from which she can select a participant is important. Peter would like to receive a notification on his cell phone when he’s invited, so he doesn’t miss an invitation. And Mia would like video chat rooms where a topic can be specified and everyone in her group can talk about it at a given time. Since the three do not immediately agree, they read forum entries and also ask their friends which functions would be helpful and what might still be missing in other programs. Thereby they realize that they already have a unique selling point: their video chat is open source and anyone can easily install and operate it on a server. They therefore decide to save all three ideas for later and to focus on the necessary functions.
Through eventstorming ( link ), the three already have a good understanding of what their video chat might look like. They mirror the interface to the defined feature set and remove all interaction options that are not needed for it. Also all events, which they do not need, are deleted for the time being. They put the features in a logical order. They want to start with marketing and back-end development at the same time. For these areas they start to estimate the duration of the implementation. The video chat should run as a web application. For this, they need a basic framework of the web interface, which they will create later. To set up the web interface, they need a test server and appropriate ways to launch applications. So they think their way through step by step until they arrive at predictable work packages for the back-end area.
For marketing, Zou wants to find out more about her target audience. She wants to use the “personas” method (more on this in a later article) and this requires research. Zou can already estimate the effort. In a few days, she should have collected and evaluated enough statistics. She thus assigns 7 points to the work package. Applying the method also takes another few days and she again gives 7 points. To document everything and to agree with the others, she estimates one point.
With this in mind, the three work their way through the areas of back-end development and marketing. For them, three things are always important:
They determine what everyone will work on over the next two weeks. They would like to briefly exchange information about the work progress every two days. With that, the three of them begin their first sprint.
In the next article, we will look over Zou’s shoulder to see how she uses the “personas” method and what she might finds out.
<< blogs