Skip to main content

Review and Estimation tasks

Many times, team members will ask you to "review" a wireframe/design, or to "estimate" a client request. This in itself can be hard to understand sometimes, as many things will probably be a bit undefined. It is often required, for the dev team to prod taskers, in order to provide more clarity of the request, or for details needed in order to provide an estimate. This is not pushback, it is in an effort to better give folks what they are asking for, and ensure all is understood moving forward.

To ensure we give taskers what they need to move forward, we first need to ensure all involved understand what, specifically, they are requesting you do.

What idfive expects dev team members to provide, may include the following​

  • Provide specific feedback, based on what the accounts team actually needs (specific functionality questions, feasibility, WCAG, etc).
  • Provide estimates for individual documented pieces of functionality.
  • Help formulate further questions, if desired, to help narrow down functionality requests.
  • Assist in general QC, for UX and Design.
  • Cross-reference any specific functionality requests from the techscan against UX/design interpretations, for feasibility.
  • Provide recommendations as to alternate approaches/easy subtractions to functionality, that could vastly assist in the build phase.

What idfive DOES NOT expect dev team members to solely provide when reviewing​

  • Decisions as to whether functionality is "in scope" or not. Your job is to provide an estimate, if requested, to the best you can, as to what an item might take to complete. The decision to modify what we propose/etc is a project team one and should probably be a conversation spearheaded by the accounts team.
  • Decisions as to "can we do this or not", in regards to scope. Again, we can provide feedback as to "what something will take to do", not any sort of final decision as to "are we going to do that thing or modify it". That is a project team decision and should be a conversation spearheaded by the accounts team.

Example initial Responses, requesting clarity of task, if required​

While you may never get all the things required in order to make an accurate estimation, the first step in response is to be sure we are all on the same page as to what is desired.

  • [Team Member], I am happy to take a look at this. Before I do, could you please clarify: Are you looking for me to evaluate if we can do [functionality specifics] in [enter number of hours] hours?
  • [Team Member], when you say "look over" these designs, are you asking me to simply assess if there are any technical FE issues, or are you asking me to assess if these can be done within a specific timeframe? If the latter, please provide further details on what that is.
  • [Team Member], you have asked for an estimate, but it appears we have little information provided about the actual functionality request. Are you asking me to provide further questions to ask, in order to get closer to an actual estimate, or to provide a ballpark range, knowing that (without further details) it could vary an extreme amount?

Reviews​

Review Tasking Tips for Taskers​

  • Be specific. If you ask someone to "look this over", what are you really asking them to do? See if all is technically possible. See if all is technically possible in [XXX] hours? etc.
  • Break down your budget. If you are asking for someone to "review and estimate what a specific component will take to build", you should have a rough idea of "how many hours you can spend" on that functionality, based on all else that needs to be accomplished in scope. It should not be "Can we do this feature as well as 'everything else' in 200 hours", but rather, "Can this specific feature be done in 25 hours".
  • Be prepared to make decisions for the project. Developers can give you an estimation of "what something will take" to build, but any discussions of "can/should we then do this", or "is there functionality we can cut" is a team decision, not something a dev should be asked to come up with directly, in a vacuum.

Review Tips for Taskees​

  • If what you are being asked to review isn't clear, ask for clarity on the role that is wished of you. See above for sample responses.
  • Double check with tasker or review techscan, to be sure what idfive's role is in this integration. Seek clarity, or be sure to outline in your response, if there is any question as to role.

Estimations​

Estimation Tasking Tips for Taskers​

  • The more details you can provide, the more accurate your estimation will be.
  • The goal is to "paint a picture" of what the end result desired is. Dev does not need you to "solve the problem" with possible solutions/etc, we simply need you to "define the problem we need to solve as best we can".
  • Expect the developer to return a ballpark range, and expect that if little details are provided, that range will be large. To minimize this range, provide as many details as possible, as well as adequate time to research/understand any more complex details, if an in-depth estimation is desired.

Estimation Tips for Taskees​

  • All you can really do, is your best educated guess, based on details provided, and time provided to review. The team understands this.
  • Provide a range. Inevitably, we will have very little in the way of specific details when estimating. Think of each request as a range, and give it your best shot.
  • If there are simple questions/details, that if provided, would drastically change the estimate, or provide a more detailed estimation, flag those to the AE.
  • Do the best you can, with what you have. It can be frustrating when asked to provide estimates based on incomplete information, but at the end of the day, we are all on the same team. There will be time for further clarity down the line if work goes forward.