6
Agile provides 3 opportunities to catch this error prior to production
The dependency should have been captured in the acceptance criteria: When story B is written, it should have been linked back to story A. And an acceptance criteria should have been written to capture that.
Unit test should break: While not all Agile teams may be writing unit tests, ...
4
Short answer
Don't formalize. Communicate more often.
Long answer
I think this situation calls for better expectation management / communication. Make explicit what you need from the customer and when, and make explicit when they can expect something back and what.
"emergency" fixes needed overnight
If you mean that the moment the customer finds bugs, ...
4
What you are discussing is a funnel for a customer feedback loop to iterate on your product.
The good news is that lots of lean startup advice exists to help and guide you solve this problem.
For an in-depth view of The Lean Startup and the measurements and metrics you should track to improve your product you can start with the Eric Reis book, Lean Startup ...
3
TL;DR
You can look at data and use inductive reasoning to formulate a hypothesis, or use deductive reasoning to define your product goals. Note that you must have a hypothesis or goal to test and measure; otherwise, you're performing the equivalent of asking random sea turtles which shoes to make for the world's fastest Olympic runner. Even then, you're ...
3
If Activity B cannot begin before Activity A is complete, it's a finish-start dependency, in PM-speak.
Alternatively, if both activities have to start at the same time (pretty rare), it's a start-start dependency.
If both activities have to end at the same time, it's a finish-finish dependency.
3
Role boundaries and swim lanes apply not only tasks and areas of decision making but also lines of accountability. And there's a difference between accountability and responsibility. In my view, the product owner is the sole owner of accountability to the end-user stakeholder. It is not shared, IMHO. The developers do own some responsibility to the ...
3
It's like continuous quality improvement. It is about continuous improvement of the customer experience. Or the person is responsible to manage / develop / improve/ increase the customer experience, e.g. over the project lifecycle.
3
What you need is formal change control.
You start by capturing the requirement on a Change Request. This should detail everything the client wants to change. If the change is significant it may also require the use of a separate Requirements Specification, but that would still be referenced in the Change Request.
Once it has been submitted to the vendor, ...
3
I'm going to describe my experiences from the point of view of a project manager in Information Services. Some of the specifics might not exactly match your specific environment, but the principles are still the same.
This sounds like a classic case of breakdown in communication between the business resources and the technical resources. This can also be a ...
2
You cannot really force a customer to provide you with the data. And you shouldn't. You're a fresh startup. Customers put trust in you, but they don't know if you'll succeed. You can't blame them for that.
For the project at hand, you should be patient with your customer. There's a variety of possible reasons for his delay (no interest, other priorities, ...
2
I think if your goal is to measure customer satisfaction, then it is irrelevant what your product owner thinks. It would make no sense to ask the product owner about customer satisfaction, in case he is the one responsible to make the customer happy. Why? Because in case he does not talk about such things with his customer, he just has assumptions about it.
...
2
You certainly need to formalize this. These are controlled via service level agreements. You have desired objectives for level of severity and criteria to determine at what identified defect will be placed. Then, you simply perform against those SLAs and awarded / penalized pursuant to your performance.
In other cases, you have a cadence for delivery. ...
1
TL;DR
You always start Customer Development with a vision and an initial strategy as process inputs, but they can and must evolve along with your business model. The Customer Development methodology is intrinsically the search for a validated and repeatable business model. Trying to develop a sustainable business model without an initial vision or strategy ...
1
Vision and strategy advances as your company expand. Thinking about and considering customer dev is an essential way to get your priorities straight because there's no such thing as "too early" when building a start-up.
If you don't know what your company is about, you won't be able to provide solution(s) to your customer(s) problem.
Though it may ...
1
Before You choose some technique You should define criteria: do You need go wider or deeper?
Probably the best strategy is:
at the beginning is to go deeper (focus) to gain best understanding what really are Customer needs,
later, at the end - go wider to show the full possible spectrum of possible sullutions
For doing that You need understand specifics ...
1
One way to capture requirements is to put it in a document (word/pdf) with as much details as you can. Mention the stated requirements, if necessary provide wireframe diagram and also state your assumptions in the requirements. And take a written sign off from the user/customer.
Usually such requirement documents should be shared on a common portal(...
1
Clients are almost never ready immediately -- even if they are the ones who find you AND they have a tight deadline. You need to work this into your pipeline and forecasts. Also, if you follow-up too often, especially if you initiated the relationship, you run a high risk of chasing them off or appearing pushy.
I have A/B tested this with my own clients and ...
1
Did you sign a contract? For services type work, I would hope there is a written agreement on what you two negotiated. That typically seals the deal and, from there, it is a matter of you maintaining and growing that relationship, checking in with them, asking for the data and getting a date on which they commit, and following up on a set cadence.
You ...
1
it really depends on why you need the data from your customers. If you just need this data to show a demo for them, then you could use some fake data or just parse a customer's site in order to get the data you need. In this case you will be able to prepare the demo for your customers without asking them. At the next meeting, they will be so satisfied ...
1
If you do not get anything up front, then they have no 'skin in the game.' Even if your setup process is extremely automated (setup a site with one click) the reason to get money from the customer is manifold:
If the customer is unwilling to put cash up front, they have no commitment
If the customer has not given you cash, they might be trying several ...
Only top voted, non community-wiki answers of a minimum length are eligible