Hot answers tagged

8

In our company we also face similar problem and I would agree to the post above that kanban is a good choice. Kanban board provides all the necesarry visibility and clarity for team, also we do stan up meetings for quick overview. During planning phase we take parts - if the planning is for first project, we invite only the members that are related. In such ...


8

Scrum Does Not Prescribe Development Practices Scrum is not a development methodology; it's a project management methodology. The Scrum process holds no specific answers for you from a requirements standpoint. Scrum Provides a Framework for Your Questions However, Scrum holds that the questions you are asking are part of the self-organizing that your team ...


7

Your question is titled about integrating into a Scrum team, but it sounds like you are not organised like a typical Scrum team would be Typically, your UX designers would be team members, they develop software, the same as your programmers. You should not create user stories for UX tasks. User stories should meet INVEST criteria. UX tasks would likely ...


6

I think this is totally possible as you need to agree on one and the most important rule. When you plan sprint backlog, you close it and there is no place for new "unexpected" work items. Because you will be forced to deliver value on each of the ongoing projects, in any other case you will fail not one project but all together. Also, it is important that ...


6

TL;DR In your rather long question, this mixture of issues stood out as the gist of what you're really asking about: Sometimes a design will be approved the first time, but other times it'll take 5 iterations. The only thought I had was to maybe re-score every time I have to do an iteration & bump it to the top of my sprint since that's still ...


6

Soliciting requirements is a iterative process, starting at an abstract level and diving down as you iterate. It is a data pull from the stakeholders; so it is about asking a ton of questions, several different ways, and becoming more tactical as you go along. Since it is a data pull, the techniques are not rocket science. It involves surveys, interviews, ...


6

This is not the purview of the Product Owner (PO). The PO should not care how the product is built - that concern lies with the Development Team. The PO should only care about what is built in what order. In my experience, purely development tasks such as these should be created by the Dev Team, not the PO. If something can be stated in a way that ...


5

Despite the fact that I agree with David that design by committee is sarcasm [and a real phenomenon, I agree with Michael Hogan too :-)], question is about examples (not about "design by committee" term). So, take a look at this article. There is a list of projects designed by committee in the "Case Studies" part: Design by Committee: The U.N. ...


5

My advice: Set aside time for your team to learn some basic UX/usability, whether it's looking over blogs or videos together or actual training. Even if you get a dedicated person later, helping your team become more T-shaped will pay dividends. Work together to create a proxy for a UX designer, i.e. a visual style guide that can be followed by almost ...


5

It's the product owners duty to define acceptance criteria. This can include usability features. For example: As a color blind user, I want to use this feature without any impediments It's the engineers duty to figure out how to do that. For example: Subtask: As a user, I want my color blindness settings from the main application to take effect when ...


5

Do your projects sequentially, one at a time. Period. And how do you prevent the fact that other projects/clients won't be waiting for a month... Think this one through: say you have three projects to do, and each one will take four weeks (with the entire team working on it). Further assume you wouldn't lose any time switching between them. If you do ...


5

I hope theres not too much redundancy to other answers, but I wanted to go in to some details about tools you might use in agile team with several projects. What we do (about 6 developers, on 2 bigger and upto 4 smaller projects at the same time) is as well combining tools from different technologies. We write specifications based on user stories, which we ...


4

I'm a little confused as to why you've been asked to teach a method you've only read about, from a field you have limited experience in? Nothing personal against you in particular, but that's usually a recipe for failure. It's one of the reasons so many 'methods' get a black eye - someone with limited experience tries to implement it, and it doesn't work ...


4

At the initial scoping phase of the project you need to understand what the client wants and what users want. Your project management skills will be tested in trying to balance both sets of requirements and deliver a product both are happy with. To understand your client's requirements use the techniques that other answers have proposed including what you'...


4

I'm not sure we've answered the OP's question: How do you prevent a situation where you have to produce work-product work first and get client feedback before getting on the right track to meet their needs? If I understand the problem correctly, the OP is working with the client to develop the initial requirements for the project (pre-initiation). The ...


3

Design-by-committee is a real phenomenon, especially in government projects where a committee of elected representatives establish and control budget decisions. University of Southern California course SAE 550, "Systems Architecting and the Political Process", is a survey of engineering efforts that have been heavily influenced by design-by-committee. The ...


3

Looks like your Scrum team does not have a Product Owner nor a Scrum Master However, if you do, get your Product Owner to prioritize the stories and get your Scrum Master to receive and manage all requests for your time. Your team (and you) should focus on one highest priority story (as decided by your Product Owner) at a time and take it to 'done' status. ...


3

Business analysts and Designers in a Scrum team Business analysts help provide detailed requirements to the dev team. So, in a Scrum team a business analyst can be a part of the Product Owner (PO) team and assist the PO. They can also step in place of the PO, when the PO is unavailable. However, designers actually do the work of creating a shippable ...


2

Would not delve in graphic design issues, since my aesthetic feeling may not be shared by others. As for eliciting customer's requirements, there are a few considerations: How do you structure and dimension your product space? a) Structure: what attributes of the product do you consider overarching and largely constraining your design? For instance, for ...


2

As another responder, Trevor, has said, it would be ideal to get consulting from someone experienced in Scrum to lead your graphic design office in taking up the most useful aspects of the methodology. That said, I recognize that not all companies and organizations have the resources, and smart people CAN learn from books and from others. So to that end, ...


2

The best place to fulfill this requirement would be your teams Definition of Done. A process policy used to ensure quality. Speak with you team about how to best test usabilility in the sprint cycle. I'm sure they will have lots of interesting ideas and a Definition of Done policy is best owned by the team. Some suggestions might be; Pair devs with UX ...


2

The short answer for me is to always have user stories. I come at this with a software dev background, many Product Managers don't have a background in development and cannot think in units of dev work. However, they can work with us on defining who are the end users, and what will they be doing with the end product. Once we can come up with a list of likely ...


2

This actually is a very good question. I've found that visual representations of system processes can really help people who don't write code understand system designs. Yet, I've also found people are hesitant to maintain and reuse such documentation. Here I present an incomplete list of reasons why reuse and sharing my be true in the hopes that someone on ...


2

I am trying to find an example of the failure of design by committee... Design by committee is not actually a serious method. It is sarcasm. Typically, that phrase is used to describe a design process that is extremely inefficient and is leading to feature-bloat. It is inefficient because it takes longer than necessary to make decisions. It leads to feature-...


2

This question is a perfect example describing one of the root problem and why many companies liking & switching to Agile Development. If you are familiar with some agile development concepts you will understand my response as is. If not try to read about scrum, product backlog, definition of done, user stories, retrospective, sprint review etc.. I ...


2

The old saying "a picture is worth more than thousand words" is also true when it comes to software specifications. You can write multiple pages of text to describe your user interface and its functionality. The result is that the reader takes an hour to read it and still has just a vague and abstract idea in their head about how the end result will look ...


2

To be blunt about the answer, it sounds like the designer has a lot of crutches. If you want them to step own design (I'll assume you do or you wouldn't have hired a designer), you need to take those away. Now, before I get into the ones I see in your description, I should add that if you take them all away at once, you may just overwhelm them - you have to ...


2

This is a question for which I have always been looking for an answer. With my experience with this, is how I am managing: These kind of technical tasks are considered 'acceptance criteria'. Or you can have a story based on your infra-requirement, like: "As a (role), I need the system to respond well when there is load of 10K concurrent requests" OR You ...


1

Firstly, design is a very personal thing and (in my experience in a similar industry) this makes it very difficult to set the 'back-and-forth' process to a specific number of iterations. I think your second suggestion is much closer to how I would approach it. To keep the back-and-forth to a minimum though, I would consider getting the client involved at ...


1

"Final Say" is a Business Decision; Consult the Framework or Charter Is is better for product or the engineers to have the final say for UX/design decisions? Or should it be a majority vote? The answer is: "Neither. Both. It depends." Your underlying assumption seems to be that authority for making decisions rests on expertise in UX or product design, ...


Only top voted, non community-wiki answers of a minimum length are eligible