Agile: Business Priority vs. Dev Logic

The crux of agile development is building features in order of business value and priority as well as accounting for change in the development process.  However, when starting from scratch on a blank canvas, it can prove difficult to build the items that the customer deems highest priority first.  Enter development (dev) logic.  Dev logic is a term I made up that means building the most basic functions, on which other functions will depend, first.  Consider this example:

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:

  • Which document will be generated?
  • What does the document look like?
  • What data goes on the document?
  • Where does the data come from?
  • Who can edit the data?

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).
For example, if Priority 1 is to have the system generate PDF documents, help your customer to see what must be done before PDF documents will be generated in terms of user stories (not technical components).  Choose statements like “User must first be able to search for the document they wish to generate” and put everything in terms of user acceptance.  Review the list of user stories that would need to be built in order for the PDF generation function to be user-testable.  Add these user-stories into your notional schedule.  Repeat for second, third, fourth (you get it) priorities.
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.

Author:
Carol Maddox

Join Our Team

View Careers

Contact an Expert

To contact one of our experts or learn more about Definitive Logic, please submit the form below.

  • This field is for validation purposes and should be left unchanged.

Contact an Expert

  • This field is for validation purposes and should be left unchanged.

Join Our Team

View Careers