I'm currently reading 'Agile Estimating and Planning' by Mike Cohn and it mentions to not split by tasks like 'build user interface' and 'build middle tier', and instead to focus on building something which you could fire a 'tracer bullet' through to cover all technical layers of a feature.
As a Product Owner, I'm not sure how this would work in practice. If we need to reduce uncertainty by building the entire user interface for an epic first before building the API, surely we should do so?
Building only a user interface prototype will not usually reduce risk. It may increase risk because it would not deliver a working product. The better approach is usually to do whatever you need to deliver a working feature or features in a single iteration, which is what Mike Cohn suggests.
Don't confuse uncertainty with delivery risk. Uncertainty is normal and is a good thing early in a piece of work. Trying to reduce uncertainty too quickly can cause more problems than it solves because it will force the team into decisions without sufficient information and user validation. Delivery risk is something different and the best way to reduce delivery risk is usually to deliver functionality in working increments.
Building the entire user interface before building the API isn't the only approach to reduce uncertainty. Another option would be to use wireframes and mockups of an appropriate level of fidelity, perhaps even increasing levels of fidelity, to get feedback from users. In parallel to this, the development team can build vertical slices of functionality, taking advantage of what they know about the user interface, but focusing on getting the data model, APIs, and algorithms right.
As the mockups become more detailed feedback from stakeholders is incorporated, the development team can iteratively improve the user interfaces. There may be small amounts of work to deal with any kind of data format changes, but in a well-architected system, the view should be independent of the data models and APIs as long as those data models and API have the necessary data.
When you use sprints to develop software, the idea is that after each sprint you should have some new - working - version of your application. You incrementally add something useful to the product with each iteration, it's not just about organizing work.
What Mike Cohn is saying there is related to the difference between vertical and horizontal development. You should try to build features vertically, that means something that traverses all the layers of your application and can be used by users. It might not be full featured, it might just be something basic, but it's something users can use and provide you feedback on. Then, in the next iteration you add some more functionality, and some more, and so on. But at each step it's something that exercises all the layers of your application.
When you do horizontal development, what tends to happen is that people think like "this sprint we do the database, next sprint we do the service layer, next sprint we do the API, and next sprint we do the UI", or something like that. When you do this, not only do you risk having to do some rework because you assumed some things at each step and when you integrate you realize that you still have a lot to do, or you have to change something, but also the feedback loop gets bigger and bigger, and you need to wait more for users to provide input on what you are building.
If it's important for you to build the UI first, to reduce uncertainty and to collect feedback, then that's not necessarily a problem as long as you are doing that mindfully, being aware of the differences between vertical and horizontal approaches. Call it a discovery phase, or an exploratory phase, or prototyping, or investigation spike, or whatever, just be aware what you are doing, and let users know that what they are seeing is not an working increment because the UI is not connecting anywhere to do useful stuff.
A better approach would be to figure out how to put an UI in front of the users to gather feedback while investing the smallest amount of effort in it. There are tools like Invision that can help you do this without actually spending time building the real thing with developers and all (it's a bunch of interactive wireframes). Once you gather your data and build your understanding on what's needed and what's the less risky approach, you can then go build the real thing.
The book probably refers to the situation when developers blindly split every task into layers. That doesn't make much sense because next step (usually QA) won't be able to start any of those tasks until all of them are done. So even if you split them - the group of tasks will still be treated as a single unit of work.
What you are referring to is creating something like a prototype - to give users/stakeholders something they can play with, to check your understanding of the domain & goals of the product. This work itself can be split into tasks that can be tested and delivered separately. But it has nothing to do with the problem that your book alludes to.
In the 1st scenario - the whole task should fit in a sprint. In the 2nd scenario you're probably dealing with something larger.
instead to focus on building something which you could fire a 'tracer bullet' through to cover all technical layers of a feature.
Split or not to split in layers can't be answered with a pro or contra in general.
Such kind of decisions must be taken on base of a lot of conditions you already have decided before. Especially:
if you already set up multiple teams where each of them is responsible for a "layer" of your software/product, you already have decided for splitting
if your software structure is build up on horizontal layers, you already have decided to provide interfaces between layers which can/must be mocked up, if development starts on (only) one side of such an interface.
if your team has knowledge on both sides of such an interface and is able to build the complete feature from "kernel" to "ui", it still can result in doing work multiple times for each new feature which is potentially to expensive and move the decision also to "split".
What I miss in general from your question: "What is your unit test strategy"?
If you have proper unit testing in your environment, there is a good chance that you will always test your ui against a mock and the "middle tier" against a ui mock. This requires a interface definition including architecture/design and a detailed feature description regarding this interface. If you are organized that way, the reason "to not split" is not longer valid, as you test against each side of your layer interface which reduces uncertainty and risk at once ( as long you do not write independent interfaces and mocks, but this is also an organizational problem ).
If your test scenario is totally different, for example you are able to test your UI with an "automated user" tool like "sikuli" or others, you can build your feature without strictly defining the interfaces and "only" define your UI and the functionality and ignore the details in all the interfaces. In such a scenario, you can easier decide to "not split" and it speeds your complete design and integration a lot and makes it easier to modify the interfaces later, as this will not brake your tests and mocks ( simply, because you have no mocks! ).
As agile development and especially scrum defines "definition of done" more or less precise with test strategies, your decision to split or not to split is directly related to your test scenario I believe, more important than your team structure.
My personal experience:
if you want to drive your software feature based, you need a good toolchain which can generate parts of the software automatically. In your example, a simple UI can be build up on the data the UI should manipulate. It will not provide any design ideas, but enables all the manual and maybe automated tests you need to implement the complete feature from top to bottom. This reduces risk and uncertainty a lot and speeds up the design definition a lot.
if you have a team which provides layouts / wireframes, you have to use automated software generation out of the wireframes. The wireframes can be shown to the customer while the functionality can be tested against provided mocks and or your real software.
if your software is very small and ui and "middle tier" is in one team, it makes sense to not split, but only if your test scenario can guarantee quality.
As we have no idea how your organization and development teams are structured, the question to split or not to split can't be answered.
I am in hope to gave you some ideas to drive your decisions not such "easy" as some book authors do :-)
"Building a new user interface, and getting approval for it," might easily be viewed as a parallel task to the "mainstream feature-release process."
For instance, while working on a loss-prevention application for a major retailer, I purposely constructed very-detailed HTML prototypes and arranged for the users to be able to see them ... by directly connecting through the company network to my computer. I told them: "first, I'm going to build it, then I'm going to make it move." And the feedback poured in. Entirely new angles on the requirement appeared when "it occurred to them to mention [for the first time ...] something."
Yes, "those were surprises." (To both sides, really.) But I made sure that they were inexpensive surprises.
And – when that process finally was finished, those HTML files became the actual templates that the actual delivered application used. Thus, I made good on my promise: "first, I'm going to build it, then I'm going to make it move." The application moved into the release cycle and was deployed – if I might say – "to grand success." Just in time for Christmas, where it saved about $300,000 in fraud losses in just that one season. "Not bad. Not bad."
So – very definitely pursue "user interface work" in parallel to the ongoing development efforts. "A static actual HTML file" can be "worth a thousand wireframes." And much easier to do.
From a sprint planning perspective, it isn't wrong but very dangerous. This is because if a developer finds a bug afterwards, you have to start all over with that side of the project because of the decision made during sprint planning and as you know, changing a code affects everything.
Thinking about it, I guess that is the reason Mike Cohn mentions to not split tasks like 'build user interface' and 'build middle tier', and instead to focus on building something which you could fire a 'tracer bullet' through to cover all technical layers of a feature.
As a product owner, you may have come across relatable situations during projects if not, it's better to be safe than sorry because situations like this has occurred and experts has concluded that the above is better.
UI-design work is a lot like API-design work because here is where you are figuring out exactly what the application is going to do ... as perceived by those who will actually use it in their daily work.
These people aren't software designers. They probably have some (manual?) process for doing the work right now. But, don't expect them to really be able to guide you in terms of software. You need to show them something – and, be able to show them something else very quickly thereafter. These are the vital inputs that will thereafter shape your team's entire effort, but you should expect to be surprised. Customers want to have an active part in developing what they will be called upon to use, but ... they are not software designers. They don't think quite like you do, and you don't think quite like they do.
My experience is that "spending serious time" on this stage is critically important because it avoids wasted time on your part. Get the blueprints worked out completely before you say that you're ready to build the house: "paper is cheap; bricks are not." Now, you can move directly toward the target with a minimum of "scrap(!) work," confident also that your customer ... is pleased already. You can execute those moves using the Scrum methodology. (Or, anything else.)
