Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
So we start Scrum today and start going over story points estimates.
The first story that comes up is a new screen that needs to be developed. It has 1 sentence to describe the screen and 3 user acceptance tests.
This starts a fight between the development team and the product owner.
Product owner says that stories do not need to be speced out and they will just be fleshed out during the sprint.
We say that the story needs to be completely speced out for the sprint.
But now I am starting to be unsure about who is right....
Any good articles on this that I can send to the team about how defined a user story has to be?
What happened during sprint planning?
It appears that you did not review the sprint plan to see the stories in advance of starting the sprint.
That's okay.
Stories are fleshed out during the sprint. That's the point. Relax.
Flesh out the story quickly, build quickly.
At some point, the one sentence story may become rather complex. If that's the case, break it up into something you will finish during the sprint, and stuff you will not finish. It's okay to have some stuff that was not known and did not get built.
Relax.
Do not overspecify everything. Do not specify every nuance of the story before the sprint. Just build something that will work. As quickly as possible. That's why it's called a "sprint".
Don't build everything you imagine. Build enough that the story can be performed by the user.
The point is to build something that works on schedule. If you have to adjust the scope of the story, that's okay.
Any good articles on this that I can send to the team about how defined a user story has to be?
A story is typically made of one sentence based on the following template: In order to <benefits>, as a <role> I want <action> (and I like to add "how to demo" steps that help to understand the story and to build acceptance tests). The idea is to capture the essence, not the details. Details are captured using face to face conversation during the sprint (and may be added as high level notes to the story). But a user story is not a contract, it's a promise for a conversation (about the scenario for which the story is the title). If you need some guidelines, following the INVEST model has worked well for us.
PS: No offense but the development team seems to react very defensively (asking for full speced things sounds like "hey, we did it as it is written", i.e. CYA). A user story leaves some space for creativity. Isn't that nice? If you need more details, take your responsibilities, go gather them. And if for any reason you can't get required clarifications or details, raise an impediment and have your ScrumMaster work on it. Personally, I enjoy having some space for creativity.
IMHO fighting is not good - Product Owner, Scrum Master and Development Team form the Scrum Team so they need to work together. They want to achieve the same thing - building a great product.
To me the question is how important it is for the Product Owner how the end result looks like. If he says: "We hired the best people on the market, you're the experts, whatever you come up with is fine with me as long as the user need is fulfilled", then I'd fine with the PO statement. But of course he can not complain afterwards that he does not like the look or the colors!
Another point is that the team needs to be confident that they can commit to this story. Usually teams estimate story size with planing poker so if the development team can not estimate, you need to invest time before that you can estimate (e.g. talking about the story before, spiking and negotiate with the PO about the story). Sometimes the designer/UX guy needs to work ahead and create mockups for the upcoming user stories.
It's always about finding the balance between planning and doing :-)
fs
I believe Martin Fowler's blog post on Conversational Stories probably answers your question best. You really don't want to be in a situation where the Product Owner is required to spec out everything in detail. You've got a team of smart, creative people that are perfectly capable of making good implementation suggestions as well as asking the right questions as they come up during the sprint. You don't want to lose out on that creativity and input by locking down requirements up front.
The story should be clear enough that the team understands what the feature is and small enough that the team can complete it in one sprint before it is added to the sprint backlog. The rest of the details should be handled via conversations during the sprint.
In our practice we do internal investigation of tickets for the next spring before planing with stakeholders. We usually find a lot of questions to clarify. If we don't answers before sprint starts we can't estimate it. If we found new issues/question during sprint we inform stakeholders and usually such story will be transferred to the next ticket.
So, my answer will be: the story don't need to be completely speced out for the sprint. But team need to know all answer to questions required for implementation as well as business decisions.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I'm not against Scrum. I love it, it's right on my second preference right after RAD, however in my current team they made me hate it. We're possibly doing it in the worst possible way.
We have the usual Sprint planning which takes roughly 30 minutes while writing user stories ourselves and that's all. Right in that 30 minute we answer questions like the following:
What should the user do?
What is needed for this (Subtasks).
How much time will it take?
Okay we're done, see you tomorrow morning in the daily stand-up meeting.
This really frustrates me and they won't listen to me. There is no planning, like at all. At the point of (2) all 4 developers talking about different ways of solving a particular problem. It would be fine, but we also don't have any clarified vision and thus everyone has different understanding of where is the whole project headed. Thus our ideas completely differs. This usually ends up in chaos. For example the most recent story in our newest shiny project's first sprint:
Vision: We need an application to perform unit testing on X application.
User stories:
User logs in
Create DB table (No schema has been clarified)
Create Login View
Authenticate user to Y server.
User sees the available unit tests
Create a view to display unit tests
Read DB table
Implement CRUD operations
User executes unit tests.
Implement selection to the upper view
Add an execute operation
Display the result in a new page
What my worries were:
Vision doesn't say anything about where this whole project is headed thus we will end up re-implementing the majority of our functions when going to the next spring, or after that, or after that... (Checked - this happened right away; I can't help it I just hate to work on something that will be erased right at the start of the next spring. I don't think Scrum is about it, it would be really useless)
No actual planning. We haven't clarified anything what the DB should look like so how to create it? I can create a DB for such a system with 1 to N tables depending on what the project should achieve in the future but this is not so serious as a DB can easily be extended.
Based on (2) we started working on different parts. I created the DB while others created views and again others created operation implementations. All of us had different understanding and even in just a day we ended up with non-compatible models that just couldn't be integrated.
What have we done wrong:
No planning. My team just hates planning, they're like act first and ask later. I'm like: I.DO.NOT.DO.SOMETHING.TWICE.BECASE.YOU.ARE.LAZY.TO.DO.PROPER.PLANNING.
No communication between team members, but even I didn't expect that just under one day we will end up like that.
What is going wrong in here? Is it just me with the wrong understanding of scrum or my worries are true? This is giving me so much stress at work I barely can handle it anymore.
I'm intrigued as to who "they" are in this line : "This really frustrates me and they won't listen to me." ?
It reads as if you're referring to the rest of the scrum team. If so, I suggest you need to get to a "we" footing as soon as possible and work on communication.
With regard to some of the items in your post, a few things come to mind immediately:
If you don't have one, you need a product owner to own the product, it's vision and it's backlog. If you do have one, they may benefit from good training or coaching
You are absolutely right about needing a Product Vision. You seem to have one but, you infer that it describes some functionality rather than a complete product vision. If so, have you tried to discuss this within your team?
If you don't have one, you need a scrum master to help the product owner and development team to play by the rules of scrum and, in your case, encourage communication within the team. If you do have one, they may benefit from good training or coaching
Concerning your worries, I would add:
I think you mean 'sprint' where you write 'spring'
It is common in scrum that product backlog items are changed to reflect better understanding
You shouldn't need to describe the database in depth when you start a project. Scrum works best with emergent architecture based on implemented functionality
If multiple developers work in the same area without communicating, it's highly likely that you will step on each other's toes and get the outcomes you describe
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
When and who undertakes the work to sufficiently gather answers so that we can start to write stories for an upcoming sprint. Is this work done continuously and in parallel to existing sprints by the product owner? I guess this then creates tasks for a sprint such as investigate x and y. What if the PO suddenly requires a developer to answer some of the questions by trying stuff out? I understand the idea of spiking and creating r & d tasks. I guess I want to avoid the main dev of a feature being delayed to a following sprint too often.
The team determines how much new story work it can do during a sprint. The amount of time they have to do that work is some percentage of the work day. Depending on the responsibilities of team members (customer support, bug fixes, emails, PTO, other duties) that amount varies from team to team. I like to see 10-15% of the work day dedicated to "planning" for the next sprint. That includes helping the PO research, writing stories, breaking up stories, design sessions, what-if scenarios, etc. I think the key is not to shoe-horn every one of these types of tasks into a sprint but rather to set the correct time allocation to doing the sprint work. Maybe something like 30 hours/wk is an average number.
So to directly answer your question; the planning work is done in parallel to the current sprint work.
We usually have one or two meetings to talk about future stories. Also, we reserve some overhead time in each sprint to check out things we need to know to start a story. The meetings help determining which stories will probably shop up in the next sprint, so we know which questions to get answers to during the reserved time in the current sprint.
For us, if it's a large project, we will have kickoff meetings to brainstorm the project. There is often a knowledge gap for PO's between what they want to do and what they don't know we can do that these meetings can fill.
When new stories are created, we try to assign story points to them at some point before the next planning meeting so the PO has time to prioritize the list before that meeting.
I'm not sure of the kind of situation you describe where a PO would "suddenly" need a dev to try stuff out. In that case, I would offer a spike in the next sprint. Generally using new technologies isn't something that happens every sprint so this should suffice. If not, perhaps the sprints are a bit too long for this purpose (a trade off to be considered at least) Another alternative would be to introduce an evergreen story for trying stuff out. I've seen teams have these kinds of stories for tech debt payback - you could off an either/or situation. Sometimes dev fixes tech debt, sometimes they try stuff out. And if you run out of tech debt somehow, you can always grab another regular story to put in its place.
We typically reserve a sprint or two after a big release for research and proof of concept stories. Doing research as part of the regular sprint seems like it would be problematic. You'd probably use that time to absorb mis-estimations for value-adding stories and end up never using it for actual research.
If a new story drops into the backlog that needs research and the PO runs it up to the top of your backlog then the team should include some research time into their actual estimate. I would only do that if I didn't have the luxury of a research/prototyping sprint ahead of time though since estimating research can be a bit nebulous.
Who: Product owner. Stories and Product backlog are his responsibilities. Product owners are generally experienced people; even if they are not technical they can certainly perceive implementation complexities at abstract level. Still, if a story has gray area PO must ask right people the right question. He can ask developers, testers, peers, clients and even scrum masters.
When: all the time.. Continuously. PO must not do anything but (1) provide (or get) answers for the team’s questions regarding scope and function, (2) and gather data that would refine the stories and their scope: thus proactively solving the queries of his team.
Bottom line is if product owner is not giving good stories to the team then he is not doing his job. Stories can be written by anyone but in the end it’s PO who ensure that Product Backlog is in order and that top priority stories are defined.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
We use Scrum. We are experiencing problems during sprints when we find the user stories are not sufficiently granular to capture the effort required to complete the sprint.
In particular, we find that we are supplied with UI wireframes that contain much more complexity than the original stories would have implied (e.g. functionality duplicated for usability reasons). This leads to the burndown chart looking like everything is completed on the final day of the sprint.
We spend the Monday at the start of each 2-week sprint going over the stories as created by the project team, during which time we typically refine the stories a little and break them down into tasks, estimating the hours for each to create the burndown chart. During this day it doesn't feel like we have time to meaningfully improve the quality of the stories.
How best to break the cycle of incomplete / insufficient stories for our sprints?
Is this a failure of the project team to nail down the stories sufficiently at the outset, or should we (i.e. the dev team) take some of the responsibility?
So are you saying that:
Customers/users talk to project team
Project team writes stories and creates wireframes
Development team breaks down stories into tasks and estimates
Is there a possibility of the development team actually talking to the customers/users? User stories are sometimes seen as a way to kick off a conversation, as opposed to requirement documents/specifications.
EDIT: Some links:
A user story is to a use case as a gazelle is to a gazebo
Six Features of a Good User Story - INVEST Model
The Customer is Always Available
EDIT: Martin Fowler made a blog post yesterday on ConversationalStories that covers this far better than I did.
Are you running sprint retrospectives? At the end of the retrospective you should have high priority actionable items to improve on what happened in the previous sprint. The same things shouldnt be going wrong repeatedly.
Is your product owner accessible during a sprint? If not you may need to add extra to any estimation as the detail of a user story is incomplete.
#Pascal suggestion to dedicate 5% of your sprint to product backlog grooming is a good one. This should enable the user stories to be in a more detailed place before the start of your sprint.
We spend the Monday at the start of
each 2-week sprint going over the
stories as created by the project
team, during which time we typically
refine the stories a little and break
them down into tasks, estimating the
hours for each to create the burndown
chart. During this day it doesn't feel
like we have time to meaningfully
improve the quality of the stories.
It sounds like this is your sprint planning session, do you have control over what user stories you are commiting to complete during the sprint? How can you commit if you dont have sufficient detail?
This takes you back to having a good retrospective and solving the issues raised.
How best to break the cycle of
incomplete / insufficient stories for
our sprints?
Retrospectives, planning, backlog grooming.
Is this a failure of the project team
to nail down the stories sufficiently
at the outset, or should we (i.e. the
dev team) take some of the
responsibility?
Its the responsibility of the team as a whole. Finding blame isnt going to give value, but everyone taking responsibility will give everyone a chance of completing the project succesfully.
Maybe during those Monday morning planning sessions you can involve whoever is writing the user stories / wireframes and work together to find out what detail is missing from them, what detail would make your estimations easier and more accurate. Maybe a template of what they should include could be drawn up.
We had (and continue to in some respects) this same problem. I think this problem is a lacking of upfront analysis and a lack of devs spending enough time estimating a user story.
You might start with a story like:
As an administrative user I can create a new widget.
OK, what does that mean? After some analysis, it might mean:
As an administrative user I can create a new widget in created status with complex data validation errors.
So after that a listing of fields, how big, and what the required fields are for saving to the database. A basic UI mock up would be nice as well.
Another user story for the next sprint might be:
As an administrative user I can edit a created widget and correct the complex data validation issue to move the widget to completed status.
Then list of the complex validation rules.
We spend the Monday at the start of each 2-week sprint going over the stories as created by the project team, during which time we typically refine the stories a little.
At the start of the sprint, the stories should be READY. If you need to refine them a bit, I think that you (the dev team, the ScrumMaster, the project team) should do that a bit ahead, during the previous sprint.
How best to break the cycle of incomplete / insufficient stories for our sprints?
You are maybe underestimating stories or they are too big and too vague. In both case, this sounds like an estimation problem and a good way to improve is to reduce the size of stories. To work on this issue, you could dedicate some time (e.g. 5% of every sprint) to Product Backlog Grooming in order to prepare the most important stories and reduce their size by putting them on diet if required before the next sprint. And this will actually make the sprint planning meeting smoother.
Is this a failure of the project team to nail down the stories sufficiently at the outset, or should we (i.e. the dev team) take some of the responsibility?
The responsibility isn't that important IMHO (except for political reasons maybe but they do not produce much value anyway), both the dev team and the project team are working together and "failing" together. What is important here is to inspect and adapt to remove the obstacle. So, it's the dev team responsibility to make this problem visible (it is an impediment). And it's the ScrumMaster responsibility to work on this impediment. The failure would be to not work on it. Backlog Grooming sessions are one way to do it. And at the end, I'm sure the project team will improve and get a better understanding of what the dev team is expecting. And you will both produce better results.
Lots of good ideas here already on the scrum aspects of your problem. Based on your comment:
particular, we find that we are supplied with UI wireframes that contain much more complexity than the original stories would have implied (e.g. functionality duplicated for usability reasons).
I also have a concern that you might need to work on you development process as well though. Accessing functionality from multiple locations in a UI should be a simple addition that consumes almost no time at all. If you are finding this to be a common problem then your functionality is too tightly coupled to particular UI elements. Your team might need to improve their design skills (eg: pattern usage).
This is interesting. It would appear that you are doing the sprint planning in the sprint? And that the Sprint Backlog is committed before the Sprint Planning? If so, how are the team commiting to the sprint backlog without discussing the details of the stories?
An alternative approach could be to make the Product Owner aware that certain stories cannot be added to the sprint backlog due to lack of clarity. In particular that the acceptance criteria are not fully understood. This could provoke the necessary conversation with the Product Owner. Ideally it shouldn't come to this. It should be discussed and resolved in the retrospective.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
What do you do if members of your team are not cooperative during scrum meetings?
They either provide a very high level definition of what they are currently working on, ("working on feature x"), or go into extremely irrelevant details, in spite of being well educated in SCRUM methodology.
This causes the scrum meeting to be ineffective and boring.
As a scrum master, what are your techniques to getting the best out of people during the meeting?
Edited to add:
What technique do you use to stop someone who is talking too much, without being offensive?
What technique do you use to encourage someone to provide a more detailed answer?
How do you react when you find yourself being the only one who listens, while other team members just sit there and maybe even fall asleep?
First of all... make sure folks are standing up... and not even leaning on the wall or a desk.
At a high level, I would say that, whenever you face issues on the team, the best response is to ask the team for solutions. However, here are some of the techniques I've used for the issues you're facing.
Talks too much
have him/her stand on one leg
have him/her hold the scrum "speaking" token in an outstretched hand while they speak.
Add a flip chart to the scrum to list tabled issues... when someone gets longwinded on a topic that is not scrum-meeting-worthy, interrupt and say "Hey - great point. I'm not sure everyone needs to discuss this, how 'bout if we park this for a follow-up discussion?" A key to making this successful is to actually follow-up afterwards and get the side conversation scheduled. Alternatively, the speaker may just say "Not necessary... I'll be working with Joe this afternoon on this" or something like that, which accomplishes the goal of reducing the windedness without the need to schedule the follow-up.
Need more detail. Is this for the scrum master's benefit or the team's?
wait until afterwards to ask the individual more detailed questions. If you think the team also needs to know them, coach the team member by conveying (in your after-scrum questioning) that "this is the sort of thing that I think Joe Smith would be helped in hearing from you, what do you think?"
Team doesn't listen.
Ask them on an individual basis. "Sally, I noticed that you don't seem to be getting much out of the Scrum. How can we adjust it to make it valuable for you?".
Post questions to others during the scrum. Like if Sally says "I integrated with Bob's code yesterday", ask Bob "how'd that go?" (I'd use this sparingly... to guard against scrums taking too long).
I've found that sometimes team members tend towards old habits by looking at the scrum master or project manager when they speak. When this happens alot, I alter my gaze to look away, which almost forces the speaker to gain eye contact with other members of the team, which may help the other members of the team to pay attention.
If time management is your problem. Get a timer and have someone buzz when you run out of time. Make sure tasks are broken down to an adequate level of granularity - any task should be anywhere between 4 hours to 2 days.. max 3 days. Anything above that break it down further before people signup to do it.
I think the three questions are:
What did you do yesterday?
What are you going to do today?
What obstacles do you see in your path?
Granular tasks (post iteration planning) should cater to bullets 1 and 2. The third actually depends on environmental conditions. The timer should over time subsconsciously jolt the members into thinking about their problems and framing short sentences. Focus on concrete obstacles instead of explaining why or preconditions or whatever. If you are talking to a single person for over 5 mins about something that only is of relevance to both of you.. stop, make a note (have a talk later at their desk) and move on.
Update: Also make sure everyone understands that 'rehearsing' before the Scrum meeting would save everyone's time. Think about what you would like to convey instead of just walking into the stand-up.
They should be saying what they achieved not what they worked on, and if they achieved nothing then what stopped them achieving.
The questions that are asked could be phrased differently
What have I completed since the last meeting?
What will I complete before the next meeting?
What is in my way (impediments)?
also it is important that the meeting is not the team reporting to the scrum master, but the team keeping in check with each other.
If people are talking straight at you the scrum master there are techniques to move the focus. Make sure you don't look at the speaker, or even move back so the sight line changes and they are forced to look at team mates as they talk. Do it subtle though :)
EDIT:
I cribbed that from
http://www.implementingscrum.com/2007/04/02/work-naked/
How do you react when you find yourself being the only one who listenes, while other team members just sit there and maybe even fall asleep?
Hmm, are you actually having stand-up meetings? It may sound hokey, but aside from making it harder for people to fall asleep, it also helps foster the feeling of a quick huddle to rather than a leisurelymeeting.
One thing that I have seen lead to an improvement is the use of a "talking stick" (we actually use a soft ball). It provides some additional focus on who is currently speaking, and makes the transition to another person more obvious.
How do you react when you find yourself being the only one who listenes, while other team members just sit there and maybe even fall asleep?
If I have already heard what the others have said I would ask a question of someone who is not paying attention about how it this might affect what they are working on. Very school teacher like, however it is enough so that they respond and engage with the meeting again.
I also agree with Kief
for your team to participate they have to see value in it, not just do it because you told them to.
The Scrum is a standup meeting, and the concept of a talking stick is an excellent point.
The key here is not that you have one or a few uncooperative team members, but is IMO, a more fundamental problem: the scrum team is supposed to be self managed, and the scrum meeting is to keep the team informed. If the other team members are not asking for clarifications and calling out the uncooperative members, then a re-education on scrum needs to happen.
Remember, the scrum master is not being reported to, s/he is just the person who removes blockages to the process. This does include facilitating the scrum meeting, but the team does have a responsibility to understand and demand clarification independent of the scrum master.
Ask for the specific details you need. People won't be aware of stuff you are interested in.
Also try to put forth some guidelines for better and effective presentation before the meeting.
Talk to them outside the scrum meeting and tell them how others may perceive their way of presenting what they are currently working on. I assume they are not deliberately non cooperative, but just not accustomed to the exact level of detail scrum meetings should have.
You may also ask them how much information they expect from others during the meeting.
By "scrum meeting", are you referring to the daily "stand up" meeting? If so, I believe those are usually timeboxed at about 15-20 minutes. So divide that time equally among everyone, and once someone uses up all their time, they can't talk. It might be harsh, but I believe that's how it's supposed to go down.
Scrum is a bottom up process, so in principle every team member should support the process.
How is the team put together? By organizational tradition or because of a common goal?
Not everybody buy into the Scrum idea, and we should respect that. Perhaps the best for all is that these members are not part of the Scrum team?
Some people just don't understand what is required. You can try to guide the conversation by using some key phrases.
If someone is giving too much detail then you can try to cut them off with a "What else". This will hint that they are done on that point. Or you can try the "OK, can we discuss that offline" type direction.
For people who don't buy into it, ask them questions about what they did and what they are going to do.
For the sake of arguement, let's say someone really has something they need to tell the team and it is going to take some time. Do you have an appropriate place, time or method (email, other type of meeting, lunch time) to do this? Just interupt the person and let them know the stand up meeting isn't the place.
Also, what problems during development does this create? If there is an error because of lack of communication, people need to be confronted on why they don't mention these things during the standup.
You can plan a maximum average time to explain what you did and what you gonna do.
About the people that are not willing to speak too much, I guess is responsibility of the scrum master to encourage that people to be a little bit more clear about his tasks.
If still people dont share what they´re doing a radical solution is use a canvas board where there people of the team have to move the task that they´re doing to his respective area(In development, ready to validation, in code review). Then you can know for sure in which task is he working.
After every daily meeting remember to ask for impediments or whatever kind of issue, sometimes people don't remember to say in his time or don't want share their issues.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
We are a small team of 3 developers (2 experienced but new to this particular business sector) developing a functionally complex product. We're using Scrum and have a demo at the end of each sprint. Its clear that the functional team have plenty of ideas but these are not well communicated to the development team and the demo poses more questions than answers.
Have you any recommendations for improving the the quality of input from the functional people?
Further info: I think part of the problem is that there are no specs or User Stories as such. Personally I think they need to be writing down some sort of requirements - what sort of things should they be writing down and to what complexity given its an agile process?
Have you tried working with your customer to define / formulate acceptance tests?
Using something like Fit to come up with these tests - would result in better specs as well as force the customer to think about what is really required. The icing on the cake is instant-doc-executable specs at the end of this process.
That is of course, if your customers are available and open to this approach. Give it a try!
If not (and that seems to be the majority - because it is less work) - calendar flash 'em - schedule meetings/telecons every week until they sing like canaries :) +1 to Dana
Sometimes the easiest way to get input from people is to force it out of them. My company used SCRUM on a project, and found very quickly that people tend to keep to themselves when they already know what they're doing. We ended up organizing weekly meetings where team members were required to display something that was learned during the week. It was forced, but it worked pretty well.
I'm a big believer in Use Cases, detailing the system behaviour in response to user actions. Collectively these can form a loose set of requirements, and in a SCRUM environment can help you prioritise the Use Cases which will form that particular sprint's implemented features.
For example, after talking to your functional team you identify 15 separate Use Cases. You prioritise the Use Cases, and decided to plan for 5 sprints. And the end of each sprint you go through and demo the product fulfilling the Use Cases implemented during the sprint, noting the feedback and amending the Use Cases.
I understand that the people you call functional people are acting as Product Owners, right?
I think part of the problem is that there are no specs or User Stories as such. Personally I think they need to be writing down some sort of requirements - what sort of things should they be writing down and to what complexity given its an agile process?
Actually, without having any specs you probably have no acceptance test for the backlog itens as well. You should ask the PO to write the user stories, I like the "As a - type of user -, I want -some goal- so that -some reason-." form. Keep in mind that the User Stories shall be INVEST - Independent, Negotiable, Valuable to users or customers, Estimable, Small and Testable. What is a must is to have the Acceptance tests written together with the story so that the team should know what the story must be able to do in order do be set as done.
Remember that as the product evolves, it's expected to the PO have ideas as he sees the working product. It's not a bad thing, actually it is one of the best thing you can get through Agile. What you have to pay attention is that this ideas mus be included in the product backlog and it needs to be prioritized by th PO. And, if it's necessary and will add value to the customer, the idea should be planned to be built in the next sprint.
Someone from the functional team should be part of the team and available to answer your questions about the features you're adding.
How can you estimate the Backlog item if they are not detailled enough ?
You could establissh a rule that Backlog item that do not have clear acceptance criteria cannot be planned.
If would be better to have someone from the functional team acting as Product Owner, to determine, choose and priotitize the Backlog items, and/or as Domain Expert.
Also, make sure everyone in both the functional team and the development team speaks the same language, so as to avoid misunderstandings ; See ubiquitous language.
Track the time most waiting for answers from the functional team as well as he time wasted developping unnecessary features or reworking existing features so that they fits the bill.
Are they participating in the stand-up meetings?
You could propose to have a representative at each (or some) of them, to ask them for input before the end of the sprint
Are you doing stand-up meetings and do you have burn down chart? I think those two areas would benefit you greatly.
I recommend the book "Practices of an agile developer" it is full of suggestions how to make a scrum team successful. It also gives good tips how to get the product owner/customer more involved and how to get the whole process rolling. It's worth the money IMHO.
I agree that you need some sort of requirements (user stories or else).
One piece of advice I can give is to use some sort of visual aids with the functional teams. When customers have plenty of ideas (as you've said) they usually also have a visual idea of what a feature looks like, when the developed product doesn't fit this visual idea it creates a lot of doubts, even if it does the job functionally.
When discussing functionality with customers, I try to be very visual. Drawing sketches on a board, or even verbally describing what something would look like. Trying to find a common visual image. You can then take a photo of the sketches and use them as part of the documentation.
Another advice is to keep your sprints as short as possible, so that you do more frequent demos. But you may already be doing this, since you didn't mention your current sprint duration.