Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
What software do you use to manage Scrum software development ?
We've tried Tackle and VersionOne (both free) so far and they are good except for the fact that it's difficult to track work in progress. For example, if I have a task that I estimate will take me 8 hours to complete, I've done 4 hours of work with 4 hours remaining, the task is always reported as 8 hours remaining until it is marked complete, at which time it falls to zero.
I'd like to use a tool that will allow me to take an accurate work at the teams WIP at the end of each week and see how much impact that work has had towards a deadline along with completed tasks.
Thanks for your input!
I recommend a white board and excel spreadsheets. The whiteboard has story cards (index cards) , where the work in progress is tracked. The story card starts out with say 8 hours, and as the work progresses decrement the number on the card. At the end of the day, put the numbers in the cards to a spreadsheet.
The whiteboard is visible all the time, and gives the whole team visibility on how the work is progressing.
This question was asked recently:.
Everything from Excel to VersionOne to Scrumworks to BaseCamp was mentioned.
Personally, though, we use a heavily customized Excel sheet, whiteboards, index cards in a variety of colors and a large corkboard.
You also might want to check out Mingle. It's a tool developed by ThoughtWorks, a company that only does Agile.
We've looked at most of the tools out there and ended up with Scrumwise. We've been using it for a while now, and it's incredibly easy to use, and does what we need. It uses the remaining time on each task to compute the burndown etc.
I note that no one has pointed out the misunderstanding of WIP (work in progress).
In agile, “it is not done until it is done”.
While most people see work done as a good thing, it is not. WIP represents investment that can not yet be realised. This is an important part of Agile, but made more explicit in Lean/Kanban.
If you track work done you will encourage developers to work on several things at once, getting everything to “80%” complete. At the end of the project you will spend 4 times more (80% of your time) in “bug fixing”, doing the last 20%. You will look like you are ahead of schedule, but you will over-run.
Also after one sprint, if work packages are small (they will be if you are doing scrum), then the error from not adding part done work to work done is insignificant.
Therefore: Track WIP separately from work done and try to keep it low.
Compromise
As a compromise, you can track part completed with the following rules:
Only track one task per developer. (probably the biggest)
Add a cap, maybe 1/2 sprint.
Discount the rate, maybe 50%, if it is 80% done then report 40%. (tweak the discount rate when you have evidence but don't let it be as high as 100%)
OnTime recently added support for Scrum management (disclaimer: I work for them and helped build the product). :) We also put together an intro video for Scrum if you need more information: Video.
I've been working on an open source web based tool that you can install on site or use our hosted version. We've got sub-task tracking and a real time planning poker feature.
http://www.scrumdo.com/
I was looking up SCRUM software and found this old topic - just my two cents ....
I worked on a project in a healthcare domain for about a year and we used Version One. I am sorry to say, it was perhaps the most despised tool in the project. The testers especially, loathed it. Neither did we developers like it as it was pretty clunky/slow and generally pretty lethargic. We always had excellent customer Support from V1 but the tool just didn't cut it for us.
I am now working in a different project and we are using www.scrumwise.com - and so far so good....
VersionOne does let you change the estimates as you go - the burndown report wouldn't work otherwise. You may be hiding the estimate column or have it set to read-only - click the spanner on the right to list available columns and make sure that the estimate/ToDo column is editable.
We've found it to be rather good, though their odd insistence on customised controls breaks in Chrome.
I would suggest checking out OnTime's Planning board because using excel and an actual white board takes away from actual development time when you can automate the process with software..
I answered a similar question at https://stackoverflow.com/a/16667842/1810290 and I thought of sharing it here as well.
If you are looking for an online scrum tool, then you could have a look at Flying Donut. It is a new online product, and I've used it in my projects with great deal of success. There is a nice way of organizing your backlog, and its GUI is clean with quick response times. It provides different iteration views for planning, execution, and review.
Disclaimer: I have been using it for many months, since I helped building it.
ScrumWorks is nice for small teams. And free, too, for the basic version. We have about 30 developers with multiple projects/iterations/etc. Some basic burn-down charts, good for "yesterday's weather", etc.
Check it out at:
http://danube.com/scrumworks/basic
I think RallyDev might be worth checking out for you. Unless I'm mistaken the way that it tracks time will not cause the issue that you mentioned above.
We have been using it on our project for several months and have grown with it to where the team enjoys using the project.
We use Scrum for Team System which is excellent, but you do need to be using Visual Studio Team System to get it!
I've used this Index card generator, but I see now that there is a newer version link that only uses Excel
I also like their Planning Poker when trying to get estimates.
Just saw this, maybe in a another stackO q/a, https://scrumy.com/demo
Check out Scrum Pig at http://www.bellacode.com. It is a great Windows tool for teams collaborating together when using Scrum.
We use RallyDev for scrum management system. And I found it very much handy.
No-one has mentioned JIRA, is that a cost/OpenSource thing?
I've used JIRA for the last 3 years and have found it to be an excellent tool.
We also use a physical board with a google spreadsheet that serves as an online replica. It works really well and doesn't really add any overhead if everyone gets in the habit of maintaining both. I've blogged about it and included a sample spreadsheet:
http://www.littlebluemonkey.com/blog/online-scrum-tools-part-1-the-scrum-board/
We have used XPlanner. It's simple, but does it's job pretty well. Especially Developers get a nice overview for their current status.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
After investigating a little bit scrum and kanban, I finally read this answer and decided to start using kanban, picking something from scrum (note that I'm working mostly by myself, and I do have read this question and its answers).
Now, my question is: which tool would be best to get started?
whiteboard and postit
agilezen.com
JIRA with greenhopper
a spreadsheet (possibly on Google Docs)
brightgreenprojects.com
Agilo
Target Process
something else (please specify)
Notes about each:
I would lean towards the whiteboard, but there are several drawbacks (e.g. cannot make automatic charts, time measurements, metrics, and sometimes I work from home - where I need it most - and it's not convenient to carry :-)
I don't want to remember another username/password (I promised to myself to signup only to OpenID-enabled services)
My employer has JIRA but my group doesn't use it - I might ask for an account (it shouldn't require another password) and maybe later involve the rest of the group. But I don't know if they are using greenhopper and if it's a big deal installing it.
I generally hate spreadsheets
maybe overkill?
I'd be happy to have a localhost instance, but it could be problematic to give access to the whole group (per network/firewalls) - not a deal-breaker but surely a concern
What I'd like to get from this?
being more productive
tracking how much time I spend in any given task, possibly discussing the issue with my supervisor
tracking what "blocks" me most often
immediately see where I am compared to my schedule
manage in a better way my long todo list (e.g. answering faster to the "what I should do next?" question)
Do you have any suggestion?
Note on the scrumish tag: read the Henrik Kniberg's PDF. He first introduced the definition of scrumish on page 9.
If I may, I think that you are on the wrong path. Anything else than 1. or 4. is overkill and pretty much useless for a non distributed team. So for a team of one person...
Seriously, if you can avoid using a web based application, just do it. First, unless you are already mastering Scrum/Kaban, you need to learn the process, not a tool. Don't let a tool dictate the process. Then most web based tools are just too much click intensive, less easy and fast to update, less transparent/visible than a spreadsheet and a physical board. They are really 2nd category options.
So, I'd go for a spreadsheet and a physical board combo. If you need some charts (I'm still wondering what kind of chart/metrics you want to generate and what value they provide), a spreadsheet is the ideal tool (but honestly, you don't need any tool to draw a burndown). If you need to work from home, take the spreadsheet (or use google docs) and post its with you. Let's be objective, the impediments you mentioned are actually not real.
Last thing, if you had chosen the simplest thing that can possibly work, you would already be doing Scrum, Scrumban or whatever. So, instead of looking for a tool, my advice would be to just start doing it.
agilezen.com seems like the ideal solution for you. I have used it in the past solo for myself and it is convenient. I would not let a prejudice against non-OpenID sites get in the way of making a good choice.
pick the tool you already have, and start using it; don't let the absence of the "perfect tool" become an excuse not to start
EDIT: pick the simplest thing that can possibly work. In your case that would be whiteboard and postit notes. These have almost no setup overhead and will provide a constant visual reminder of what you're supposed to be doing.
And I suggest that you get used to making decisions on your own, as you're going to have to be your own Scrum Master ;-)
In the interests of diversity ;-) www.kanbantool.com has just launched too. It's open beta and seems at first glance even more "lightweight" than agilezen.
Target process is good too
We've been using JIRA with Greenhopper for a few months, in an effort to go agile. I use it for both Scrum for development, as well as for my personal kanban. The software is pretty flexible, and I'm going to keep with it. The story/subtask management is really handy, and it's fairly easy to use. One thing I like is that you can add stories/cards quickly, and can customize the data. This allowed me to add definition of done fields, work order numbers, etc.
In short, we're happy with it.
Bright Green have just launched a free version of their tool. It looks good .. the free version is fully functional too: https://signup.brightgreenprojects.com/plan/Free
I've tried out another kanban product for personal use and am absolutely loving this one. Feels lightweight and simple but actually packs in a fair amount of functionality at the same time.
www.kanbanery.com (free for personal use)
A novel tool not mentioned before is getsmartQ (out of beta since Dec 2010)
Key characteristics: very intuitive, supports LWP, customizable forms, and task discussions
Pros
configurable workflow, mark overdue stories, mail notifications (e.g., for upcoming story deadlines), multiple story owners
Stories form completely customizable, per project workflow and story forms, different roles (people only creating stories)
very responsive GUI with partial updates
Apparently good support: I've asked a question and got a good answer within a few hours
Cons
no easy way to declare something as blocked or to distinguish type (feature/bug/..)
no API
no subtasks or story dependencies
In comparison to Agilezen it has a more sophisticated notification system, but apart from that still lacks important features (see cons above).
Note, getsmartQ is under active development and hence missing features mentioned above may have been implemented in the meantime.
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 6 years ago.
Improve this question
Where I work we've recently put together what we call the Development Standards Committee which is tasked with improving our procedures, processes, methodologies, tools, standards, and whatever we think would help us become a more effective team.
We've got a spreadsheet of items that we've ranked and are going to start tackling from the top down. We've got things such as better source control (currently on SourceSafe), implement a bug tracker (such as Mantis of FogBugz), peer code review, move to .Net 3.5, possibly move to some form of Agile, do more actual team development rather than single developer per project type stuff, and some other things...
What do you think are some key things that can make or break a development team? What should we add to this list?
Some additional information: We have about 12 people on our windows team, and about fifty in development if you include all platforms. We want to improve as much as possible for everyone, but we're our biggest focus is the Windows team. All of us have been here for a couple of years at least, so most of us know each other and work together pretty well.
The number of people on your team is actually really important here. There are basic things that every team should implement (source code control, bug tracking, etc), but there are things that are different base don team size. Code reviews on a very small team, for instance, can be more informal.
Moving to Agile is a good idea, unless you're particular development environment makes it a bad idea. Also, you'll not be able to do this without support from the people who are using your software.
Consider doing things to ensure that communication between the team is easier and with less roadblocks - do all your members know each other pretty well? Can you work with each other? Do you understand each other's idiosyncracies? Learning to work as a team is much more important than any random process improvements you can make.
Require comments when you check in code (it's great if you can tie commits back to your bug tracker)
Maybe Static Code analysis, like what's built into Visual Studio
Continuous Integration like CruiseControl
Development teams really need good people to start with, that work well together, but this isn't really an item to add to the list. It does however affect my first recommendation, be pragmatic. If you're not encouraging your developers to think about how they work and can drive them selves to improve, it's really hard to lay down a development environment that will do it for them.
Mentor and Training: If you can't do XP, then at least hook up your Juniors with Seniors whenever you can. Not only will you share knowledge but you'll share the context around your projects you own.
Some sort of Continous Integration and regular, tested, working "releases" make wonders for quality.
as better source control (currently on SourceSafe)
If this is Visual SourceSafe -- you need to change this immediately. Try cvs, svn or even something paid like Perforce.
There exists something called Rational Unified Process that deals with your problem (and much more).
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
In my work experience, most fresh out of school programmers are set right to creating reports for 6-12 months or so. While I see the benefit of doing something non-crucial, it seems to really discourage them.
So my question is, should organizations allow newbies to work with someone experienced right off the bat, obviously doing non-critical phases of a project, do get a real feel for what their career choice has in stock, or throw them on reports out of the gate?
Ah, there really is nothing like exploiting interns for remedial jobs...
Seriously though, you get back what you put in. Forcing them to do a thoughtless, thankless job for a long period of time is a quick way to build up a useless team member.
Perhaps they should be looking for a job at different companies? Maybe they shouldn't settle?
I was once a fresh-grad, and I have never been asked to work on a report. I had a programming check-in within the first 5 days of my job.
Maybe I am confused about the question. We are talking about folks who apply for programming positions and are sent to doing "reports" related job?!
I didn't start in "reports". I started on a conversion -- just get stuff to run on the new platform. Relatively safe, minor programming changes.
Then I did some new development for a while.
Then another conversion.
Then -- 2 years into my career -- no longer a complete n00b -- I wound up in "Reports". They wanted something like a dozen dumb-as-dirt accounting reports. Each was a "pull from the general ledger", "do some quick math" and "write a columnar report". [It was 1980, that's how stuff was done.]
I couldn't stand to do copy-and-paste programming. So I wrote a thing that extracted from the ledger into an array of values. It used a flexible notation for doing calculations on values in that array, then it wrote out the results of the calculations.
It could add, subtract, multiply and divide. You could use multiple operations on a series of "cells" to compute wonderfully complex things. To a limit.
I had invented the spreadsheet, built as a COBOL batch program. Seriously. That's what putting someone on reports can lead to. A single program that produced the dozen dumb-as-dirt financial reports. And a large number of additional reports, too.
Bonus. It was built in an Agile, incremental fashion. The first version did a half-dozen of the really easy reports. The next one did two or three more.
I don't think "reports" is a bad gig. What's bad is forcing people to copy and paste yet another dumb-as-dirt report program from a cookie-cutter template.
I believe it to be beneficial. It's what happened to me long ago and it provided me an opportunity to learn the database schema, the domain, and how the data is being used.
But, if they were hired as a Software Engineer they shouldn't be a report writer indefinitely. Programmer/Analyst however...
It's beneficial to the company in the short run, because then you can get useful work out of new graduates. It's harmful to everyone in the long run, because creating reports isn't really that hard, so the newbies don't learn much from doing it.
That being said, 6-12 months is a really long time to stick anybody on doing reports (unless they enjoy it, which most people don't). Maybe a shorter time period would be better training for a new employee.
I've worked in shops that threw a lot at the new hires where the results were mixed and I've worked at shops where they did pointless monkey-business exercises such as writing reports that nobody would read, attending 'process' meetings and open-ended tasks like "read a book about C++" or "learn something about this technology or that one. Both of these approaches were a waste of effort and time.
At my shop, if you are the new guy you aren't going to get left to your own devices to figure out X or to create busy work for yourself. Typically, we'll run you through our products so you are familiar with them as a user, then we'll talk through whatever task it is we need you to do, do the "I'm right over here, tell me if you need assistance" thing and then check up on them during the morning "what are you working on?" meeting. The goal at my shop is to get a developer up to speed as quickly as possible without skipping over the important stuff.
I think the key to successfully developing the new employee, particularly one who may be right out of school is to challenge them, provide them with interesting tasking that will make them not dread coming to work. If you get them interested in the work, you get an employee who becomes valuable. There are some tasks that just aren't interesting, and we all do them at my place. For me, I dread getting anywhere near MS Word to write formal documentation, but that comes with the territory sometimes. The 'new guy' needs to realize it won't always be code slinging or new development. Sometimes it is maintenance coding - much of the time it is. Sometimes it is 'turn the crank' type work. Sometimes it is report writing.
A good manager or senior developer will mentor the new hire. If a shop doesn't do that, I'd probably not want to work there myself.
They should be pair programming (or spectator programming) with different people from their department for a few weeks. Then they get to know all the people, the structure, the code and useful tips.
Reports are a wonderful introduction.
They tend to have very specific specifications, unlike many other projects. They're a good "stand alone" task. They also give the developer a good introduction to the domain model, which they must use to actually get the data out for the report.
Finally, they're (typically) reasonably simple with some reporting framework doing most of the heavy lifting for them. So they need to focus on learning the tools of the trade, deployment, and the data model.
They're a nice gradual introduction to the larger domain and application.
I've never been put on a non-important job as a safety function. Even when I didn't know exactly what I was doing I got put on important projects people wanted yesterday, and then paired with someone who had specific development he/she wanted to offload onto the new-hire.
It works pretty well that way.
If you put a college grad on report-writing duty for a long time, he's going to bail on you. Bad management and a waste of money...
I have two contrasting experiences with Crystal Reports in two different companies:
With my first employer (fresh out of University), our Crystal Reports expert was leaving, so I was asked to take over the role. No actual training was provided, so I had to learn everything on-the-job, with no support from either the Vendor or the Employer. Although my position description was as an IT Developer, I eventually spent 100% of my time working on Crystal Reports. It was an unproductive experience for me, and a waste of manpower and resources.
My current employer asked me to assist another Developer in creating and maintaining their Crystal Reports setup. Because they provided adequate training, and I was mentored in the role, I gained knowledge on multiple systems and databases. I even a little experience at administrating and maintaining SQL Server. And I also got the chance to interact with many different clients in the company, as many different sections of the company needed these reports.
So my answer to the original question is that it really depends on the organization, rather than the central concept. If your employer is intending to use it as a way of familiarizing new employees with multiple systems, then I think it's a great idea. If it's just a short-term way of foisting a thankless (and rotten) job on a hapless new employee, then I think it's a waste of manpower and resources.
The good thing about reports is that they are not updating information so there's no chance that any data will be lost.
Depending on what the tools are for reporting too. When I did reporting, I learned tons about SQL, and stored procedures. Of course that is probably not the norm for reporting.
It depends on the report, and it depends on the job. Many reports are anything but trivial, and excellent SQL skills are needed to create a performant and properly maintainable back-end. If your newbies are good with SQL, let them cut their teeth on the queries. It will be a good way for them to learn the schema of your database.
However, if "putting them on reports" is just a euphamism for them trying in vain for hours without direction or inspiration to format a table in Crystal reports 25 (or whatever the current version is), well, I think you probably already know my answer to that question...
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
RPO 1.0 (Runtime Page Optimizer) is a recently (today?) released component for ASP and Sharepoint that compresses, combines and minifies (I can’t believe that is a real word) Javascript, CSS and other things.
What is interesting is that it was developed for ActionThis.com a NZ shop that saw at TechEd last year. They built a site that quickly needed to be trimmed down due to the deployment scale and this seems to be the result of some of that effort.
Anyone have any comments? Is it worthwhile evaluating this?
http://www.getrpo.com/Product/HowItWorks
Update
I downloaded this yesterday and gave it a whirl on our site. The site is large, complex and uses a lot of javascript, css, ajax, jquery etc as well as URL rewriters and so on. The installation was too easy to be true and I had to bang my head against it a few times to get it to work. The trick... entries in the correct place in the web.config and a close read through the AdvancedSetup.txt to flip settings manually. The site renders mostly correctly but there are a few issues which are probably due to the naming off css classed - it will require some close attention and a lot of testing to make sure that it fits, but so far it looks good and well worth the cost.
Second Update We are busy trying to get RPO hooked up. There are a couple of problems with character encoding and possibly with the composition of some of our scripts. I have to point out that the response and support from the vendor has been very positive and proactive
Third Update I went ahead and went ahead with the process of getting RPO integrated into the site that I was involved in. Although there were some hiccups, the RPO people were very helpful and put a lot of effort into improving the product and making it fit in our environment. It is definitely a no-brainer to use RPO - the cost for features means that it is simple to just go ahead and implement it. Job done. Move on to next task
I decided to answer this question again after evalutating it a little.
The image combining is really amazing
The CSS and Javascript is nicely minified
All files are cached on the server meaning that the server isn't cained every time it makes a request
The caching is performed at a browser level, meaning it will still work if you use an old (unsupported) browser because you'll just recieve the page un-compressed
You can see the difference youself Optimized vs Unoptimized
The price is as follows...
$499 until the end of september is a steal
$199 for an annual renewal is a steal
I love how RPO is plug and play.
It will take time to create a module like theirs and depending on work load can be worth the $750/year versus the development time it takes to re-create it.
I'm very excited about RPO and reviewing it's effect on my sites.
Something I used quite recently was page optimization module from I found on Darksider's blog. It it not nearly as intense as what RPO sets out to achieve, but a nice start block to building your own optimization module if that's what you're after.
Clarification on the RPO price. Launch price until end of September 2008 is $499 - and this discount is by voucher (email service#getrpo.com to get a voucher). This includes software assurrance for 12 months, after which you can choose to renew for $199 or not - the software still works.
The RPO automates 8 of Steve Souders/Yahoo's principles for High Performance Web Sites - the important thing for us was making a developer friendly tool - you can keep your resources in the format and structure that makes sense for development and the optimization happens at runtime.
I don't want to spam this forum with sales stuff, so just email me if you have any questions - ed.robinson#aptimize.net. Thanks for looking at the RPO.
Ed Robinson, Chief Executive Officer, Aptimize Ltd
I've been a user of the RPO since beta and have it deployed in anger on two of my sites:
http://www.syringe.net.nz (My blog) and
http://www.medrecruit.com (A company in which I have an interest)
I've done a longish winded blog post on the whole why not just turn on caching question here:
http://www.syringe.net.nz/2008/10/21/RuntimePageOptimizerWhyNotJustEnableCachingInIIS.aspx
The short summary version- Caching is a nice to have for people who aren't really geared up to turn it on in IIS (it's still not super easy in IIS6)... the real power is in combining resources as it's latency * request count that really kills your performance.
minifying and gzipping commonly called scripts and style sheets is totally worthwhile - the file size reduction speaks for itself. That's something that you can do through your webserver, without the help of another product.
However, merging scripts and styles and serving them together is an interesting idea from a general 'the fewer requests the better' standpoint.
It looks like interesting technology - I'd try it out. It almost certainly couldn't hurt.
Just had a little look, a lot of the things they offer you should be able to do yourself with a little palnning and foresight (combine all javascript files, combine all css, minify, enable GZip...
$750 a year seems a little steep, and theres no options.
(edit)
After speaking with the marketing bods, it's $499 until end of september, and renewing the liscence will be $199. That persuades me a lot more!
I'm going to give it a whirl and then see how much it improves our DEV server.
I personally have been using a product called PageBlaster by Snapsis that does caching, minification. It is primarily used in DotNetNuke applications, but if I recall correctly it can be used with any ASP.NET application, and the price is right.....
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.