In addition to those described in the article, i have following question on my list: # Risk * What are the platform constraints? * What are the performance c

In addition to those described in the article, i have following question on my list: # Risk * What are the platform constraints? * What are the performance constraints? * Get clarity to what is an acceptable upper bound. * Would it be acceptable if it took a week to calculate or 20 minutes to open the application? * Does it need to happen in 30 seconds or 5 milliseconds or 100 microseconds? * Can you demonstrate a failure? * What happens when you go off script? * Most of the complexity is in handling those off-script behaviors. If that’s not being handled well, the project is definitely not “nearly done”. # Definition of done * How does the “Definition of Done” look like? Ideally from whole project down to single stories. * How would you verify that this is working correctly? * What is the success criteria of this product? * What does “good” look like? * What will make it a worthwhile endeavor? * What are other pain points and blockers? # Costs ## Opportunity costs * Is this the most valuable thing we can be doing? * Is an 80% solution good enough for your needs? * Is this work really where your team can add unique value? Other question one might ask to get a feel for the lost opportunities: * Which parts of the current system are hard to use? * Which manual process stops the customer to do more creative, value-adding work? * What changes would improve operational inefficiencies and save money from the bottom line? * What evidence can you show that this will solve the problem? * Provide a simulation or prototype or fake (but statistically relevant) data which can demonstrate the solution is at least plausible. ## What connects to this? * Things with a more complex network of dependencies will be more costly to develop and maintain. * What systems will depend on this? * What systems will this depend on? Enumerate all the dependencies. Other systems, libraries, users, protocols, everything ## What’s Plan B if this doesn’t work? * What are you going to do when we’re up against a deadline, this solution isn’t working as expected, everything is broken, and we still have to ship? * Get an answer to that, then do that first. Then you can talk about how you can make it better. * What would be the earliest point you can know whether the system has any value to you? What is the smallest step that would give us the most benefit? How will we do this? * If we could keep only half the features what would they be? * What if we take one dev away from this project? * The 80/50 Rule: If you’re not 80% done by the time you’ve used 50% of your resources, you are behind. When something doesn’t pass this test, it’s time to evaluate what needs to change: * Does this project need to stop? * Do other projects need to move? “I can make up the time” is not a realistic response. # Maintenance cost * How long will the system survive? * When will this system be scheduled for replacement? * During what period will you be making no changes to the system except for critical bug fixes? * What are the prerequisites for using the solution? * What must continue to be true? * What do users need to know? * What does the data need to look like?