12

I'm the Project Manager for a large application that customers use to collect data on whether their businesses meet certain medical and financial standards. They generally answer a survey explaining how their surgery meets/doesn't meet the standards.

The application has a tool to analyse this information, so that owners of a group of surgeries can see overall how the surgeries equipment are doing .

The owners of the groups are asking for the data to be exportable to Excel or word. I've posed this to our development team, and they don't believe that exporting huge excel or word sheets of data is worthwhile. There arguments are based on:

  • The data could be huge to export
  • There is no way for them to do anything useful with that many pages
  • How would this work for users who use the iphone/android app of the tool

I'm in between a rock an a hard place with them and I'm not sure how best to convince them that this is what we need to do (short of putting my foot down and demanding it!).

  • 14
    A quick answer is that the scrum team doesn't get to decide what is or isn't a user requirement. – Grimm The Opiner Aug 11 '15 at 10:20
  • 3
    Are we talking about exporting... Raw Data to excel? Or summarized data? Partial data sets? 100k lines of denormalized raw data is different than summaries and pivot tables, for example. I would balk at the first (not to the point of "I won't do it" - if the customer wants it...) and would try to find out what the customer is trying to learn... I doubt JoeSchmo wants raw data... they want relevant information. – WernerCD Aug 11 '15 at 14:15
  • 2
    I've seen this developer reluctance about exporting to Excel before. I think it boils down to the developers not understanding how the users work with the data. They don't understand that Excel is to the users what something like Visual Studio is to the developers; a versatile tool that allows them to quickly reformat and restructure data in infinite ways. No pre-built application can anticipate all those ad-hoc needs. You may have to put your foot down. – Ask About Monica Aug 11 '15 at 18:28
  • I believe this question should benefit from some rewording, focusing on the underlying question around how to have the development team understands the requirements. – Tiago Cardoso Aug 11 '15 at 20:56
  • In addition to the answer below: one user story that could help the development is the desire to code the open answers, a common technique in data analysis: find out the common answers, assign these to categories, and then analyse the categorical data. This is something that I'm sure excel can do very well, and is a solid user story. Once you start talking in terms of user stories instead of customer demands, developers will find it easier to understand users. – Peter Aug 12 '15 at 9:45
13

Exporting to Excel is a solution, not a requirement. You need to go back to the owners and get them to detail their functional requirements for the data. Once done, then hand it over to the developers and let them propose a solution. It may end up being Excel because, as you wrote, it's already there, or it might be another solution that meets the requirements.

You have to bang each solution up against their benefits, costs, risks, and other penalties. The fact that Excel is already there and they know how to use it is certainly a benefit, but the owners might not know of or are under estimating the impacts of some of the penalties they will have using Excel and end up in the long term unhappy. In contrast, building a new solution will cost money and take time and they will have to learn it--costs and penalties--but it may cure of the impacts of Excel and, in the long run make them happy.

None of this you know yet; this has to be analyzed and a case built for each solution. But everything starts with getting proper requirements from the owners.

  • It can also be a requirement. If the target team uses Excel as their tool of choice for data manipulation then they should not have to justify a request to "Export to Excel-readable file", that is the users' requirement! – Marv Mills Aug 13 '15 at 8:14
  • I see what you are saying but I still am hesitant to agree. I think the requirement remains the ability to manipulate data. The fact that Excel is what they may have been using is still an input into the benefits/cost/risk/penalty analysis. In my practice, I try to remain tool agnostic as possible when collecting requirements. However, at the end of the day, if the customer demands it, then Excel would become the requirement. But I would attempt to steer them away from it. – David Espina Aug 13 '15 at 11:06
10

As a principle, whether having an Excel is "worth" (business-wise) or not isn't up to the development team to decide. They have to be able to tell whether it's feasible, and objectively tell what are the pros and cons (i.e. it won't work when you have more than 1.000.000 rows of data), they can also advise the client on whether this really solves their problem or not (and if not, constructively be able to propose another valid solution), but they can't refuse to implement a feature just because they think it's worthless.

That said maybe the problem has not been analysed enough, and the dev team and the client are clearly not on the same page yet; so personally I'd put them together so that they can better understand the problem and collaborate to find the best solution. The client might not have fully expressed his real need, and the development team can maybe come up with a different idea...

  • Thanks for this. They have actually brought up that there are issues (e.g. having 100,000 rows of data), and they've suggested that they make the analysis tool in the app more "excel" like. However, I can't see the need for this because a) excel already exists so why not just use that, especially if customers are happy with it. b) it'll be months of work to design and implement a change to the analysis tool to make it tabled and more "excel-like". – Yannis Aug 11 '15 at 11:41
  • 7
    I'm developer and I understand the worries of your devs. Exporting to Excel proprietary format can be painful depending on the language and libraries at hand. Maybe you can suggest compromise and export to CSV, which is text format visualizable in Excel, but easy to export. This way your users can see if it is feasible and devs won't waste time on it. – jnovacho Aug 11 '15 at 12:49
  • TIOBE top 10: Java (poi), C (xlsLib), C++ (LibExcel), C# (Open XML), Python (openpyxl), Obj-C (LibXL for iOS), PHP (PHPExcel), VB.NET (Pretty sure this isn't a problem... uhh...), Javascript (js-xlsx), PERL (Spreadsheet::WriteExcel). I've literally never had a problem reading or writing Excel in any language I've had to work with... – corsiKa Aug 11 '15 at 23:19
  • 1
    @jnovancho Most likely the users would consider that an "Excel export" and have no idea that there's a difference. – Peter Aug 12 '15 at 9:47
  • 1
    @corsiKa while those libraries do exist, specifically writing to an excel format compared to using a library to write out a csv, or xml, or json is significantly more difficult. If there is no compelling requirement that only exists within those libraries ("we want the output to be pretty with colors and borders - ready to print; and inline formulas so that things update properly when we change the data"), writing to a '.xls' file rather than a '.csv' file may be a bit of wasted effort if all that is desired is the data. – user4469 Aug 12 '15 at 13:12
3

I would change my mindset from "How can I convince them?" to "Do the user really want to Export to Excel?" and "What solution would be make my client happier while making money?"

  1. Talk with the stakeholders. They might think of Excel as a familiar way to describe the functionality. (A solution, not the requirement). But they might prefer Excel anyway (A direct requirement). In this case:
  2. Look for alternatives. For example, CSV files can be opened by Excel and are easier to compare. They are usables on Linux and Mac and it should be easier to develop.
  3. Make clear to the customer that you will make whatever solution he wants. At this point you are not worried about working more hours. You are worried about developing a solution that might not work for them. Afterwards you might talk about costs if it is an issue.
  4. Make sure that the client understands the problems. For example, you could create two dummy Excel files and tell them. "How would you compare them?"
  5. Check if the data is too big for Excel and some conservative performance metrics (It might take one hour to export to Excel in a nightly batch proceess)
  6. Ask "What do you plan to do with this Excels?". A backup? You should be able to backup the database. A report? Could you generate the report automatically?
  7. Once the customer takes a decision send the minute to have a written proof that they accepted the consecuences. Make sure to keep the email easy to find.
  8. Explain to the development team that this is a direct requirement from the customer. Not from yourself and your efforts to look for a better solution. Thanks them for their input. Even if the customer was inflexible you will be better off having explained the potencial issues beforehand.
0

I work in a very small office and have to for-fill a lot of the Scrum roles myself, so I have to balance the sides and arguments in my head for such decisions, this one was a simple decision for me, even though the Backend guy was unable to do the task (I do my own now).

I created xml spreadsheets for Excel based on what is actually displayed in an Actionscript DataTable (one huge string put in a notepad saved as .xml), besides a CSV copy of Flash Datatables.

The creation of Excel spreadsheets at the back end is trivial I can not conceive of a scenario that makes arguing over doing it are worth the time rather than just doing the request. Even turning the 1 datatable into a 3 sheet excel with parameters dates and disclaimers was not particularly difficult.

I work very closely with clients but I am never 100% sure what all of their end requirements are, giving them excel outputs means they can do the 80% of all the possible uses and interpretations of the data for 20% of the effort.

The important thing was not to get the excel in the software but to get the real problem out of the team.

0

Thinking as a technical person If the information is being stored in a database of some description its typically not too difficult to grant read only access to the tables that the users want to see and then have them import the data directly from excel bypassing the application front-end (developers don't have to do anything) either using excels data import functions or using customised VBA scripts.

Thinking as a manager Talk to your Business Analyst to add the requirement in a meaningful form or alternatively ask the Product Owner / Project Sponsor / boss like person to prioritise the work. It does sound like you are in a 'solution mind frame', which is not the job of a PM. Just because people love excel doesn't mean that they actually need an export to excel feature, sometimes this can lead to security risks.

0

You could simply put your foot down, and give the customer what they want, but so long as the developers don't get why the feature is useful, they're unlikely to implement it in a useful way. They'll give you a pointless Excel export, which won't be used, and they'll get to say "see, I told you so".

I think the best thing to do is to bridge the gap between the users and the developers. Take a few developers, preferably the ones closest to the front-end, and the ones that are most 'people friendly', and have them shadow the users for a day. Let the users show them what they want to achieve and why it's useful to them. At worst, you'll make sure that the feature actually does what the users want (rather than what they say they want) and at best, the users and developers will reach a more creative solution that really solves the problem.

After all, it's not the user's job to design the software, and it's not the developer's job to choose the requirements. They have to work together to create something of value.

Then, if you really want to get it right, get the users and the developers to wireframe some mockups together. Test these mockups on other users to make sure they understand and then discuss them with the team before implementing them.

Ultimately, this is the sort of stuff that your interaction designer/ux manager should do. It's understandable if you don't have one of those, but I recommend working towards having one. Take this as an exercise. Send three developers to interact with the users. Pick the one that the users responded to the best, and who seemd to like the exercise the most, and start giving him/her more design-like responsibilities. Not design as in photoshopping what the buttons should look like, but design as in collecting user stories, mocking up and usertesting potential features, and working with the other developers to figure out the implementation details.

0

Exporting large data sets to Excel can be very powerful and make your application that much more valuable to many more users. Excel has such a rich feature set that to try to duplicate it would be a waste of your developers' industry knowledge.

Users can filter, sort, chart, and pivot in Excel in nearly any way they choose. Are you able to define every possible workflow the users need and add that to your app? What about the user that wants to do some data spelunking and try some non-obvious pivots?

As for huge data sets the question is how huge? Exporting to a database for Business Analytics may be a better choice if the data set is large enough to choke Excel. More data gives me a larger sample size and confidence, so I don't see this as a negative.

As for mobile users, I don't know that I'm doing any heavy analysis on my iPhone. If I can get reports on my phone bring it on. Don't let this stop you!

Finally, I agree 100% with Grimm the Opiner, "the scrum team doesn't get to decide what is or isn't a user requirement". This is clearly up to the product owner.

Not the answer you're looking for? Browse other questions tagged or ask your own question.