2

In our end of sprint meetings with the client, we show the work done during the sprint then go over what will be in the next sprint. In the later, we usually show the wire frame for a visual.

I created a wireframe for a page we will be working on the next sprint, that contains a search feature (just a textbox with a button) and other stuff. It was mentioned that I should remove the search box because that is going to be built in a later sprint and just have a note saying something to that regard "to be built later" or whatever.

So I wondering if I need to limit the wireframe diagrams to only show what we are working on or is it ok to draw the entire page and just be like, "This sprint we will be working on getting this page going. As discussed we will be building the blah and blah, then the search blah will be built in a later sprint"

Improve this question
2
  • 1
    It sounds like a regular business and sales issue - showing the client a product you don't have. Does the client know about the feature? Why do you want to show it now?
    – moot
    Apr 6, 2018 at 22:12
  • 3
    I would show the entire page to give context to the client where the particular feature will be and how it will interact with the rest of the page. The feature by itself, IMO, cannot be properly reviewed without context. Decisions made on the feature should be based on how it could impact the rest of the page. So the best thing to do is to show the entire page and highlight the feature on the page. Give the client a complete picture as well as the details.
    – Chairman Meow
    Apr 6, 2018 at 22:22

2 Answers 2

Reset to default
3

Exactly how much you do when probably depends on the circumstances, but I can't think of any case where the wireframe should omit something because it will be done later - that puts way too much permanence on your wireframe. Generally speaking, wireframes aren't a blueprint, they're a sketch, so they are meant to quickly capture what you're thinking in a concrete way to make collaboration easier. Putting a search field in a corner just says you'd expect to see it up there, not that it's going to happen soon or maybe even ever.

Keep in mind too that we build increments of a product in Scrum. There are exceptions, but for most teams, this means that the UX design of a particular page or feature will evolve and change many times over the life of the application. That the team is looking to you for a design they will build as is raises the question for me of if they're using your talents as a designer to the fullest or if they're just checking off the UX box.

Improve this answer
1

Yes, wireframes should reflect sprints. It acts as specifications and expectations of what is to be built within a sprint. Also, showing clients something other than what they will be receiving at the end of a sprint, might lead to scope creep.

Keep in mind that you don't need one single set of wireframes per project. I suggest starting off with an overarching, high level set to indicate where the project is heading. For each sprint, take the relevant section/s from this set and flesh them out to suit the sprint. Only include that which will be implemented in the sprint - but be sure to keep conversations open and the overarching wireframes accessible to your team. Developers will often optimise code for future additions, if they know what's to come.

Don't be afraid to have your overarching wireframes evolve over time, as it is almost inevitable in an agile environment. Just create a new version and share it with your team liberally.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.