- About Us
General Scope: Customer wants a system to generate documents with certain data on them. The system should provide a review/approval process for these documents. Additionally, the system should send email notifications based on status of the documents. The customer also wants some other things (not relevant to this example, so not listed here).
Scenario: At the beginning of the project, the customer tells you that the absolutely highest priority is for the system to generate PDF documents. Your team has nothing but a development environment setup at this point. Your development team is asking questions like:
You should be able to get those questions answered with relative ease. But what those questions are telling you is that the first thing you build will not be PDF document generation. Your customer expects features to be built in order of business priority. What do you do?
There’s definitely a way to avoid the dilemma described above.
The Introduction of Dev Logic – Joint Design
Don’t freak out. This is not a 6 month design phase that you’d do in a typical waterfall/SDLC effort. Don’t question your agility because you have a day or two of joint design with your customer. Take a deep breath and proceed.
Start by inviting your lead developer/architect (if not your entire development team), analyst (if you have one), and Product Owner (PO) to a joint design session. Allow the PO to extend the invitation to any other power users of your product. Diversity in user types will be good for you. During the session do the following things:
1. Go over the requirements/user stories that you already know. Ensure that you and your customer are on the same page.
2. Begin talking about how the user will navigate through the system and any processes that the system will facilitate for those Step 1 requirements. Help your customer visualize. Draw things on a white board. Put together a flowchart. This will likely open your customer up to other requirements that you didn’t already know … which is good. Document these additional reqs and add them to whatever visualization you are using.
3. Work with your PO to understand priority.
4. Finally, build out a notional schedule of what features will get built during each sprint. If you’re going to have 10 sprints, assign each feature that you know today to one of those. Also do any necessary alignment back to the release plan, if you have one. It’s best to visualize this as well. This can easily be done by drawing a large table on your whiteboard. Put the Sprint names/numbers as column headers across the top. Then list the features that you plan to build in each sprint underneath. This is where you INSERT DEV LOGIC (all caps for drama).
By spending the time to do these things, you will ensure that your team understands every known requirement or user story and that your customer understands that while PDF generation is the top priority, it will not be the first story completed. In a well-oiled scrum team, dev logic should ultimately prevail. However, setting these expectations with your customer ahead of time will lead to happier customers, happier project teams and greater success.