How do you (the developer) deal with fuzzy requirements and several existing software?

Question

Here's another question trying to figure out how Scrum can / should work in real life. Here is a typical scenario that I come across:

Note. The term "product owner" is not used below. This is because the true "product owner" - the product manager in this case - does not make final decisions. The host DB has the last word in many ways, as it decides how the application interacts with the database. QA has its own ideas on how things should look / work - and their ideas are introduced as errors and are usually expected (by everyone) to be treated as such.

• The product manager writes this story: "X The user needs a page to make Y."
• At a sprint planning meeting, the story is added to lag behind the sprint.
• Some bad developers capture (or assign) a story.
• The developer asks the product manager: "How do you want the page to look like."
• The product manager (if available) says: "Hmm, well, he needs to assemble A, B and C."
• The developer begins to work on his best guess as to what should be.
• The developer tries to connect the page to the Stored Proc and asks DB a few questions. DB lead says: "The page also needs D and E. And B is not needed."
• The developer makes changes and commits it.
• QA says: "I think E is confusing."
• The developer has to argue, trying to get QA, DB lead and Product Manager to agree on what the last page should be.

My understanding (according to how we were taught in the fight) is that it is the responsibility of the developer to determine the requirements for this page. In our environment, as shown above, this creates a frustrating experience for the developer, as well as a lot of time wasted for the developer, expecting to get all the credentials that should come to a unified decision on what the requirements are.

Sometimes it may take several hours for several days to repulse the requirements for a task by 2 hours! It's hard enough to get enough time with 1 person - even harder for 3!

I know this is an anti-fight, but it seems to me that the Product Manager, database manager and QA team should meet before the planning meeting and pass on the details of the tasks that will be added to the sprint. (Developers rarely have any data that is being reviewed, and when we tried to do this at meetings, it might take a whole day — don’t joke — to hash all the details for all the elements in the lag.)

Has anyone dealt with this? Any suggestions? I don’t want to chat too long, so let me know if you need more information.

Thanks!

Answer 1

This is because the true “Product Owner” - the Product Manager in this case - does not make the final decision.

And that is exactly your problem. Scrum says

The owner of the product is not a person, he is the role. Everyone can be a Product Owner.

If your product manager cannot make these decisions, he is not the owner of the IMHO product. In this case, find someone who can make these decisions, as this is your real owner of the product.

I, since the developer (the “Team” role in the scrum) needs only to figure out how the product owner expects this feature. He is the owner, he explains to me what the page should look like, and I will do it according to its description. Lead DB is not the owner of the product. QA is not the owner of the product. I made the page what the product owner wanted, and if the DB manual or QA has a problem with this, they should talk to the product owner. Or actually the product owner should have talked to them beforehand.

Also, why wasn't there a DB and OK guide at the sprint planning meeting if they somehow served product owners? In this case, they could immediately scream “objection” when the product manager said that A, B and C. DB lead could say that he needed D and E, and B should not be there. And QA might say, they think E is confusing. As long as people who finally need to approve of my implementation after the sprint do not even agree on what they want to have, I will not touch on this thing at all.

Answer 2

I noticed some things ...

1) You mentioned that the developer pulls out a user story

Indeed, it should be broken down into tasks during planning.

2) You mentioned that a hash is needed all day.

Sprint planning can take all day. It would be better for you to spend this time right away and get enough information to move forward in the right direction than to spend so much time on a review.

Answer 3

My suggestion would be that the software be the owner of the tasks in terms of determining the expected behavior. This could mean going through a dozen or more weird cases where the system built for Y also needs to do something, if Z is not working or W is not responding on time, etc.

While the developer can describe the details, this is just asking the question to the right person. For software to say that “Oh, I'm sorry, I need D and E right now,” because part of the process is to handle the changing requirements so that the key is on the outcome, and not 101 steps have been taken to prepare the new version of the product by the end sprint.

Another option is to have a team leader or team leader, development manager, who should be separated from the project, if in a large company, be a resource to go where you could say: "I want to make D, but I need more specifics and can't plan a meeting with the software, "and we hope that this person is more fortunate.

Answer 4

The problem is not "Scrum in conflict with the real world." The problem is that "I expect good things from Scrum, despite other problems."

The main reason for your problems is that someone does not want to wait for interested parties. Everything else is a workaround for this problem. Getting a developer early with an incomplete story causes an unpleasant dance between Developer, DBA and QA. And to start early - it does not help.

DBA and QA could not trigger snapshots if you had a continuous, consistent user history. You can exceed your contribution if you had details.

You cannot blame your current process (or Scrum as a whole) because you do not have reliable user stories from your interested parties.

Sometimes it may take several hours for several days to repulse the requirements for a task by 2 hours! It's hard enough to get enough time with 1 person - even harder for 3!

You make this sound bad. 2 days of conversation to cover up the requirements, followed by two hours of technical work, is a good ratio. This indicates concern and thought. This shows that you are doing the right thing.

Be careful with the overlay of tasks for work that are designed so that the developer works so that he does not start working with scissors.

If it takes several days for a correct story, then what can I say? It takes days. Spend your days. This is what you need.

Do not tell the developer because they are not encoded. The first one who starts coding loses.

Decision

When software cannot imagine a future state endowed with the authority of software, you need to introduce someone who is a technology visionary. Sometimes they call this role a "business analyst." Some business analysts are cabinet designers and architects. Fire them. Some business analysts can help software crystallize a vision of a new way of working with new software. Reward them.

Answer 5

It sounds like you are confusing Scrum and XP Game Planning . Of course, you can customize the methodology according to the needs of your organization, but even as an XP Planning game, I think it makes no sense.

The basic premise of Game Planning or Sprint Planning is that developers or “pigs” (including DB leadership and QA) waive the right to indicate the “what” and “when” of the product to interested parties or “chickens” (Product Manager). Therefore, certainly not the “anti-Scrum” that those who are able to determine the “what” meet in advance to discuss details or priorities in order to lead to a table.

As I answered here , the details are filled in behind Sprint. It may be in the form of user stories, but the Sprint Backlog further reduces design and tasks.

Answer 6

A few suggestions:

Context : "X User needs page to execute Y" missing context. I like the crop of "Like X, I want to make Y so I can Z." This is a little different, but part Z adds the context of what the user is trying to accomplish.

Acceptance criteria . You have not specified acceptance criteria. The plot should include a list of acceptance criteria to indicate when the story will be completed. I like the phrase "Given X, when Y, Then Z" (for example, " Given that user X is logged in and has a positive bank balance , when he goes to page Y , and then he sees an emoticon next to his balance ". There will usually be a list of these acceptance criteria.

I think you will find that the Product Manager, when he is forced to determine acceptance criteria, will develop a better point of view on what he is trying to accomplish with the story, and can convey it in more detail. In addition: I also find it useful for testers to analyze eligibility criteria for testability issues.

Which is compared to how . It seems like you keep arguing during the iteration about what needs to be done. The concept of turnover in the criteria of the history of INVEST * is more focused on how the story is introduced. What needs to be defined before adding the story to the iteration.

* INVEST - independent, contractual, valuable, evaluated, small, verifiable

Answer 7

You probably do not need to meet before a planning meeting, but only when conflicts are detected. It is probably easiest to hold a quick meeting with all interested parties and make a decision that everyone can agree on.

Just because you grasp does not mean that after that you should not have smaller target meetings.

Answer 8

It is the responsibility of the developer to ensure that he fully understands what he needs to do in the givrn task. If any requirement is unclear, you should ask for a clean up until the developer and his peers / manager understand what needs to be done.

You should ask questions such as “how would we determine the successful completion of this task” or “how will the client expect this”, etc.

The developer must make sure that he fully understands what he needs to do in the next cycle before the end of the iteration planning meeting. In the event that any requirement is still unclear, it should be considered at the SCRUM meeting as something that impedes the achievement of your goals.

Answer 9

uh, wouldn’t it be easier to talk to all interested parties, then design / implement the story?

EDIT: Based on the comments and a more thorough reading of the original question, I think you might call your process “agile” or “scrum”, but actually it is not. Based on your initial points, this is what I think is going wrong [caveat: I'm not everything that is familiar with scrum, but I have been using XP for several years]:

• The product manager writes this story: "X The user needs a page to make Y."

  • The product manager is not a client, and he is not a developer. User stories must be written by the client and developer. So this step is not XP / Agile, it is a waterfall. If "User X" needs a page for "Y", you and user X should write a story about Y. Only then the developer and user will have a general idea of ​​the story, which is a whole series of users of the story. The prime minister said: “Go write a page for user X to make Y” - this is not a story, this is a task. So it looks like your team fell off the van from the start.

• At a sprint planning meeting, the story is added behind the sprint.

  • so now sprint backup is just a list of tasks created by PM. You have already hired my friend, this is not a flexible method, this is traditional project management, disguised as a flexible method.

• Some bad developers capture (or assign) a story.

  • Let’s see, since the story is a place for conversation, and the goal is for the developer and the client to write the story together, to provide an understanding on which to base the conversation, and then randomly assign the story (which is actually the PM task) to a developer who is not had this conversation, is also not agile - it's just the assignment of a task under the assumption of all-programmers-are-interchangable-cogs-in-the machine, which, of course, is absurd

• The developer asks the product manager: "How do you want the page to be like."

• The product manager (if available) says: "Hmm, well, he needs to collect A, B and C."

  • once again, PM is not a customer; who cares what the prime minister thinks about the page? The important thing is that user X thinks about the page.

• The developer begins to work on his best guess as to what should be.

I am going to stop now because I am depressed. It is not movable, it is ridiculous:

• the client is not involved in the story
• the developer is not involved in the story
• There is no dialogue between the developer and the client.
• PM does things up
• assignments compiled by PM are handed over to random developers

How should this be an agile method? He doesn’t call it movable - it’s all about the principles of the method, not the terminology. No wonder the process fails!

Answer 10

I have not yet been involved in a fight (although I studied it and loved it), but it seems to me that the Prime Minister is not doing his job if the user story is actually as barebone as you indicate. As for the practicality of passing your day: call one meeting with all three parties and make a hash through it, rather than trying to be an intermediary.

Answer 11

My understanding (according to how we were taught in the fight) is that it is the responsibility of the developer to determine the requirements for this page.

Yes and no.

Yes, if you can implement the task from start to finish.

No, if your code interacts with someone else's or user I / O in different ways, then you need an agreement on code / user interface specifications. The most important thing that cannot be done, and how to get around it, if necessary.

In our environment, as shown in the figure above, this leads to a frustrating experience for the developer since there is a lot of time for the developer, waiting to get all the authority that should come to a unified decision about what requirements are.

I know what it is! You do not work in my place? :)

Here is an example of the real world that I had to go through:

• The designer is developing a user interface page. This is about displaying hierarchical HTML pages and has buttons on the top and right, sort of like a tabbed dialog, but with tabs on both sides. Mockup looks good and seems reasonable, no problem. Accompanied by some detailed description of what this dialogue can do, etc. Everything seems to be done and said.
• The designer really gives me the task of implementing data structures for this in our database. This is unusual, but the scrum master was informed. However, communication was a little tough for both of us because of the language barrier both in the human language and the fact that he is a designer and I am a programmer from another module.
• I am working on implementing tables in a database and adding a user interface for this database frontend application. I make several assumptions about minor problems, as is usually the case with most tasks that I get. I also adapt (normalize as much as possible) the data that I received, and told how it is used in the dialog box, so that it best fits the design of the database frontend application. Several questions come that I'm trying to solve, because one of the design requirements will either explode exponentially (the database), or become unusable in the interface if I did the usual denormalization. So I decided to buy a buy-in for this, which I received, but, unfortunately, it turned out to be a big misunderstanding biting us later.
• Further, the programmer exporting the database has several questions. I answer them. I reworked several things to make it easier to export things, so we are working on some limitations of our work environment. Other questions just need clarification of the "unusual and confusing terminology" that the designer used.
• The third programmer begins work on introducing the layout of the design interface. Some questions immediately arise. Additional settings are made in the database tables. Suddenly, I decided to do something that is difficult for me to implement in the application of the external interface of the database, but I was able to get around it. However, the DB exporting programmer must also rewrite some of the code, and he is not happy with the new data layout.
• Now we found out that in the first part there was a big misunderstanding. I get another remake task to redo 50% of the work. Fortunately, no one has yet entered production data into the database, so I could opt out of most of them. However, the task is already taken 3 times longer than originally expected.
• Again, this applies to the exporter and user interface programmer adding more time to it.
• Finally, someone begins to enter production data into the database interface and does not know how to work with it. He discovers that he is communicating between two programmers: a UI programmer and a DB interface programmer (s), who both have different views on the task. More alterations are being done, but most of the time is spent explaining how everything works.

This is just a very concise and small part of the story. It is not interesting to read, I suppose, I can’t give a lot of details and don’t want to remember everything that happened. What were the main problems in this example?

• Designer unfamiliar with database and interface
• DB programmer unfamiliar with user interface design.
• Database developer and programmer have misunderstandings, each of which makes its own assumptions based on their experience.
• concessions are made in technical design to accommodate the limitations of the database interface and the database exporter
• avoiding writing costum code in the database interface and export, as this would remove the initial task evaluation for a long time
• Due to constant requirements and changes in implementation, there has always been confusion. It is strengthened by the fact that we did not work on this together at the same time, but one at a time in a matter of days or even weeks between them.

But the biggest problems of all: Inter-Pod communication. Everyone is used to working inside their container, and since people know each other and what they do, not everything needs to be explained or written down in detail. However, as soon as the conversation with other members of the group began, no one expected that communication would be so difficult. People wanted to find out the seemingly obvious things in great detail. Some questions simply don’t “stick” and reappear. This was unpleasant for all participants, which further limited the effectiveness of communication.

What I get: communication is key, and when other pods are involved that usually don't work together, the communication overhead can be quadrupled. If you are not ready for this, this can lead to frustration, demotivation, lack of implementation, etc.

The more people used to working with each other, the less they need to communicate. The converse is equally true. Keep this in mind and plan ahead.

Answer 12

My team is constantly facing this problem. We get very wide user stories and ask for a couple of them for a 2-week iteration. We spend a week talking with our OO (we work on different sites), detailing the details of one user story (if we are lucky, we can do two), and write our own user stories so that function / reception tests can be written against them. Then we begin to evaluate the difficulties of each of them and make a commitment on how much we can really hope to complete in the rest of the week.

Invariably, one extensive user story is broken down into at least 6 or 7 more subtle user stories. This gives us an idea of ​​how complex the wider user story really is, and by repeating this, we hope that we will contact our software to give us more subtle user stories, but so far we have not had much success.

As S. Lott said in his answer , if you get vague or too high-level user stories, you should play the role of a business analyst to bridge the gap between the software and the development team.

Answer 13

I know this is an anti-fight

I suggest that you (and your teammates) not focus too much on being "Scrum", "anti-Scrum", "XP" or anything else.

You are the creators of the software, and as such, I encourage you to trust yourself to be the best people and professionals to create the software that you are paid to create, regardless of what books or consultants say about a flexible (or any other methodology)

but it seems to me that the Product Manager, the database manager and the QA team should meet before the planning meeting and see the details of the tasks that will be added to the sprint

Agree with you.

This is what I have successfully done with the many (flexible) teams that I have been to. This practice helps you better understand the work that needs to be done and appreciate the complexity. This is not about writing specification documents in a few weeks, but about understanding better what is behind the story, both on the functional and the technical side. A wiki page (or similar tool) is often enough to collect such information.

when we tried to do this at meetings, it might take a whole day — not joking — to hash all the details for all the elements in the lag.

Yes, it may take a long time to hash all the details, and in most cases this is not necessary. This is a balance between getting information and getting too much information. Filling a wiki page (screen size) often enough. Obtaining this information can be from 10 minutes to 2 hours.

If it takes more time, this is probably because the story is quite large and / or vague, and you might consider how to share it.

I hope for this help.