Decide what is worth building.
Start with the problem, turn uncertainty into questions, and define a first release that can be evaluated.
A useful place to start.
A short reading path
- 01How to write a software brief a team can actually use
Frame the problem and the next decision.
- 02Map the workflow before you automate it
Observe the real process and its exceptions.
- 03Write acceptance criteria around behavior
Agree what a working outcome looks like.
Explore the topic.
How to write a software brief a team can actually useA useful brief connects a problem to a decision. It gives a delivery team enough context to ask better questions without pretending every implementation choice is settled.Map the workflow before you automate itAutomation makes a process repeatable. Before investing in it, establish which steps are intentional, which exist because of current tools, and which nobody can explain.Choose a first release that answers a real questionA first release should make a useful task possible and expose an important uncertainty. A collection of disconnected screens can satisfy a feature checklist while teaching very little.Turn feature requests into problems you can solvePeople usually request features in the language of the tools they know. The request is useful evidence, but it is worth understanding the situation that produced it before choosing an implementation.Prioritize a backlog without pretending every score is preciseA backlog is a list of possible work, not a promise to complete everything. Prioritization is most useful when it exposes the reasons behind a decision and the uncertainty around it.Write acceptance criteria around behaviorAcceptance criteria turn an abstract request into behavior that people can inspect. They should clarify the boundary of the work while leaving room for implementation decisions.Run a discovery session that produces decisionsA discovery session should reduce a specific uncertainty. Bringing everyone into a room without a clear question often produces a long feature list and little shared understanding.Handle scope changes without losing the original goalNew information will change a software project. The useful discipline is to make the effect of a change visible before the team quietly absorbs it into the work.Make uncertainty visible in software estimatesAn estimate is a planning tool built from what is currently known. Its usefulness depends on explaining the assumptions that could change it, rather than presenting uncertainty as an exact date.Decide what should stay manualA task being repetitive does not automatically make it a good automation target. Some work changes too often, happens too rarely, or relies on judgment that has not yet been made explicit.
Put it to work
Commercial software
Connect the guidance to the application or systems you need to build or improve.
Explore the service ↗Engineering context
Technical publications
For work involving Gray, read the published technical material before treating language or runtime capabilities as project assumptions.
Read the technical work ↗