Detailed Capacity Planning

A more detailed Capacity Planning feature would allow us to better manage our roadmaps from the perspective of what is achievable based on our current resource levels. The following high level features would be included in a more robust capacity planning module:

  1. Ability to define specific resources that make up a team (not necessarily Aha! users).
    1. Define resource name and position.
    2. Define the skills that each resource has (i.e. development, documentation, user story writing, etc.).
    3. Define the percentage or amount of time each resource has in each period to work on roadmap items.
  2. Ability to estimate the amount of time needed for each skill type against a feature.
  3. Ability to schedule each feature to a specific resource.
  4. See a visualization of each resource's capacity, assigned work and remaining capacity by skill type.
  5. See a visualization of each team's capacity, assigned work and remaining capacity by skill type.
  • Gravatar Jeff Moore
  • Nov 25 2014
  • Planned
Release time frame 6 months
  • Attach files
  • Guest commented
    December 22, 2014 05:00

    This would be my Aha nirvana.

    Please implement aha gods

  • Juri Pietersen commented
    January 20, 2015 20:51

    This is for me the most important improvement that Aha could make!

     

  • Mandy Long commented
    January 29, 2015 16:50

    Agreed. this is a huge struggle for us. Right now we intervene through custom fields and excel spreadsheets to try to track across role types... it's not pretty and hard to maintain.

  • Geraldine Reffreger commented
    February 12, 2015 08:45

    I'd love to see this feature implemented. It  would really help us visualize who is overloaded and re-arrange tasks appropriately for a more effective resource and capacity management.

  • Jason Kayser commented
    February 24, 2015 15:16

    This is a critical function for GE to adopt this tool widely.

  • Mandy Long commented
    March 19, 2015 01:38

    Huge impact for us!!!! Cannot wait.

  • Bryan Lawson commented
    April 15, 2015 14:38

    Would greatly help my planning and communicating to and up the organization!!

  • Guest commented
    May 5, 2015 23:28

    yep, yep, yep ... will make release planning accurately a reality.

    Agree with "This is for me the most important improvement that Aha could make!"

  • Tarun Sachdeva commented
    May 12, 2015 18:11

    Echo what everyone else is saying - being able to manage individuals in Aha (especially by release) would help greatly. 

  • Mandy Long commented
    June 5, 2015 18:52

    This would be amazing for us - currently doing in Excel spreadsheets and trying to manually map back. What does "planned" mean from a timeline standpoint? Is there a release that this is projected for?

  • Young Soon Dusart commented
    June 19, 2015 08:08

    all of the above greatly needed.

  • Andras Bori commented
    July 5, 2015 23:24

    Need visibility into resource allocation to releases.

  • Guest commented
    August 6, 2015 04:29

    Capacity planning and tracking at the phase level of the data model would also be of great benefit to us.

  • dan ireland commented
    August 10, 2015 11:23

    Just to add some more awesomeness to capacity planning in general... it would be great if when creating a filtered list I could see:
    - original estimate
    - logged time
    - remaining time
    - overspend

    As we integrate with JIRA, remaining hits 0 when the logged time is > than estimate

    If we could see overspend as a separate item, it would very easy to quickly scan a list of tickets and see which one we underestimated. This helps future sprint capacity planning by retrospectively understanding how well we planned last sprint and how we can improve.

    Please make it happen :)

  • Guest commented
    August 24, 2015 22:25

    Please also refer to APP-I-1526, as it makes sense to be part of your plan when improving the capacity planning.

    Track effort (estimates) to prepare features for JIRA separately

    When Aha!-JIRA integration is enabled, updating the features estimates on one of the tools, will cause an update on the other.

    We suggest to have the possibility to un-map the estimates fields between the 2 tools. So updating on one tool won't affect the other.

    We would like to have separate estimates on features on both JIRA and Aha!. Where these estimates don't relate to each others.

    Aha! users (Product managers), they use estimates in Aha! to bring the feature to "ready to develop" state. While JIRA users (developers), they use JIRA estimates to bring the features to "ready to ship" state.

    In our case, both estimates are different and shouldn't overlap. 

  • tom bailey commented
    August 25, 2015 09:13

    Yes please!

  • Tom Andries commented
    August 30, 2015 15:36

    It is essential for us to have an as early as possible warning of resource overload in order to keep the strategic exercise realistic. While one might do an unconstrained strategic exercise first, it needs to be double checked for feasibility anyhow - resource availability being one of the feasibility factors -. Furthermore, we need to zoom in / scale up between all levels of product and resource plan.

    For us, estimates MUST be the same in JIRA as in AHA, so I suggest the uncoupling of estimates becomes an integration parameter that the AHA user can toggle on or off.

  • Dmitry Grenader commented
    September 17, 2015 18:49

    i see a need for it during roadmap planning in particular, and there are two angles:
    1. Here are the "boxes" of functionality I want, what amount of resources do I need when
    2. Here are the resources I have, when / how soon / how much can I do on the roadmap

  • Cal Hamilton commented
    September 18, 2015 18:53

    This would be extremely valuable to my organization. One additional ask here is to support Capacity Planning for teams that have continuous development or agile scrum development cycles. In JIRA, our team conducts weekly sprints with potentially shippable increments each week. If Aha.io allowed for Capacity Planning, it would be important to keep in mind that Dev teams work on weekly releases as opposed to long term product/feature releases as mapped in Aha.io. Thus, Aha.io would need to be able to understand that "capacity" would need to be set at the weekly dev cycle capacity as opposed to a higher level Release capacity. A Release in Aha.io might require 5 weeks of development to deliver those features. Thus, capacity would need to be mapped according to how many "features" or "user stories" could be delivered each week. This ultimately results in a better and more realistic estimate of when the Aha.io Release date should be set to. Given the dev team's capacity, can they deliver the Release features in 3 weeks? 5 weeks? 10 weeks? etc...

  • Tom Andries commented
    September 20, 2015 09:35

    I would like to refer to Axosoft's Release Planner. Peace of cake to plan releases taking capacity into account with their Release Planner. If we could do the same in Aha!, it would become my one and only tool for managing, from strategy all the way down into execution. Now I have to use Aha! for something in-between because our main strategist might not be convinced of the advantage, and detailed planning is out of scope for Aha!. As a result, I need to put up with at least two tools and manual syncs between them. Sad, because of (a) stupid sync work and (b) two fights to do for acquiring the right tool.

  • Tom Andries commented
    September 20, 2015 09:53

    As to the way detailed capacity is planned, again I refer to Axosoft's Release Planner: detailed work (features and their subtasks as well as tasks at the same level as features) are assigned to ... a SPRINT, and SPRINTS are assigned to a RELEASE. For us, master releases are defined by technical boundaries (test/build/deploy), containing several product-related sub releases (way of organizing features and presenting them outside the production division). While production work is indeed organized to a large extent in sprints. So we should be able to define a sprint (or a sub sub release that we can call whatever we like to call) and move features (task, ..) from the parent (sub)release to it.

  • Tom Andries commented
    September 20, 2015 12:41

    It's important that capacity be checked at the resource level across releases. People tend to work at different releases in the same period, so the current capacity per release is worthless. I first need to figure out who much each person is going to work on each release - which, in our case, doesn't makes sense - before I'm able to indicate a "release capacity".

    As we have parallel sub releases (one for each product), capacity might make sense on the master release level. But even then, releases may overlap. Next year, we'll have two minor and one minor release each quarter, so the major will overlap with the minor (leaving room for less urgent or more demanding features) and thus ... use the same resources (capacity).

  • Mandy Long commented
    September 30, 2015 14:51

    Is there an update on the estimated delivery timeframe for this? We are struggling with multiple tools, excel, etc and it's creating a lot of friction. Really really really need this tool!

  • Admin
    Brian de Haaff commented
    October 7, 2015 23:31

    Thanks for all of the support for this feature. We appreciate the attention you have given to explaining the benefits and how you would like to see it work. Clearly, it would be a significant addition. We are trying to scope it and would appreciate knowing a bit more about who is asking for it. So, if you have added a comment, please add another one with your title. We are trying to understand if this is coming from product or engineering management (or both). There is no "right" answer, we are just trying to understand who is driving the interest. 

  • Ross Reynolds (External) commented
    October 8, 2015 00:21

    Hi Brian - I'm a Director of Product in a B2B Company with 7 products to track.

    We would use this feature primarily in our product planning sessions with Engineering where we decide what to work on in the next 1-2 sprints and for quarterly roadmap planning.

    Our general use case is to T-shirt size initiatives and features, and then put them into releases where a fixed team/capacity is assigned.  Once we're at capacity, we leave off low priority features and let the team know that the list is our commit for the quarter and everything "below the line" is a stretch goal.  These features would help us plan better.  Jira does not actually do a good job of helping map out long term goals, just sprints.  For my persona, simple is better.  It's about release planning, team capacity, and what's above or below the line for the next 1-2 quarters.  Sprints and individual capacity is planned in Jira.  

  • Mandy Long commented
    October 8, 2015 00:24

    Senior Director of Product Management. I'm writing the request but it is being driven from the following roles on our team: Director of Engineering, Director of Mobile, Director of Cloud Services, and me.

  • Andras Bori commented
    October 8, 2015 00:46

    Andras Bori Director PMO

  • Guest commented
    October 8, 2015 02:38

    Digital Product and Program Manager

    I would add to this list the ability to capacity plan by Phase rather than Release. It's highly unlikely that anyone can do meaningful capacity planning at an entire release level, given all of teh various phase likely to be involved in a release.

  • Guest commented
    October 8, 2015 04:45

    Hi Brian, we use Aha in an IT consulting context, and detailed capacity planning would simplify assignment and calculation of our resources to various project ( products ), and where we are under and over resourced, and when resources are available to roll onto projects. Thanks.

  • C K commented
    October 8, 2015 05:09

    Product Manager. I'm writing the request but it is being driven from the following roles on our team: Director of Engineering and myself.

  • Dmitry Mezentsev commented
    October 8, 2015 08:13

    Dmitry Mezentsev, VP Engineering

  • Guest commented
    October 8, 2015 08:18

    Technical Program Manager. This is coming from both engineering and product management.

  • Emilie Takeda commented
    October 8, 2015 09:30

    From our company: product managers and release manager. We are currently managing partially this in JIRA... so integration with JIRA would be necessary.

  • Dmitry Grenader commented
    October 8, 2015 11:47

    @Brian de Haaff  Yes, am interested in this. Dmitry Grenader, Director Product Management at Luminoso, Inc. dgrenader@luminoso.com

  • Dmitry Grenader commented
    October 8, 2015 11:50

    @Brian de Haaff  - I would gladly talk about this with you.  My ask is for a part of it frankly - specifically how capacity relates to roadmap planning.

  • Brian Dreyer commented
    October 8, 2015 13:01

    Director of Product Management....JIRA's reporting is awful and we do separate capacity's for engineering and QA so this would go a long way in helping us capacity plan for releases.  Not mention your reporting is much better so this would only feed into reports used to communicate with senior management.

  • matt geffken commented
    October 8, 2015 14:39

    Sr Dir of Product Management.  

    A single Agile Release Train in our environment utilizes both feature and component teams.  If feature-based teams can deliver the entire release, release planning becomes (relatively speaking) easy when features are estimated and team capacities are known.  In our hybrid environment (feature-based Team A works on Product 1 and feature-based Team B works on Product 2, but component-based Team C works on Product 1 AND Product 2),  we're forced to create complicated networks of "critical path" spreadsheets to determine the feasibility of our plans.    Of course, the problem gets much more complicated as the number of teams and products in a single ART increase....as it does in my organization.  

  • Guest commented
    October 8, 2015 14:41

    Senior Manager, Enterprise Business Systems.

     

    We use Aha for our application portfolio release planning and roadmap.  The primary goal of the release planning is to allocate right resources to application enhancements throughout the lifecycle of application portfolio.  With over 120 applications and 20-30 resources available to allocate it is important for us to estimate effort and time of each resource, and identify conflicts and gaps.  As well, with resource estimations we can provide a more realistic release plans to our executives so that they know when to expect their enhancements.

     

    This is a much needed functionality that will add significant credibility to application roadmaps.

     

    When will this be delivered?

  • Ronnie Trowbridge commented
    October 8, 2015 21:37

    This is the one feature that is missing to make Aha! the perfect planning tool. If there was a visual way to see need vs. capacity over time (maybe quarters) that would be helpful, too. I could then see what I have and what I need at a high level. Please, get tis to us soon!

  • Admin
    Brian de Haaff commented
    October 8, 2015 23:20

    Thanks for the additional follow up and comments. Please note that we did just rollout the ability to see estimates and work completed on the Feature Workflow screen.  It does not solve all of these use cases, but it helps you visualize who is doing what and the effort surrounding their work. You can even filter it down to a specific release and reallocate the work.

    As I mentioned, detailed capacity planning is significant in terms of value and scope. You know that we move fast, very fast, but this is going to take us some time to get our arms around and prioritize. It is definitely planned and an emerging priority, but there is no delivery timeframe yet. We will keep you posted as it gets closer. Also, if you have specific ideas about how it should work and want to share rough mockups, you can always send those to us at support@aha.io For example, what screens do you imagine this impacting? 

  • Jeff Moore commented
    October 9, 2015 11:53

    VP, Development and Delivery.

    We are a technology company (hardware and software) in the Public Transportation space.

    Being able to forecast what capacity we need for a given release will help us tremendously. We would be able to plan for when we need to hire developers or what projects need to be prioritized and moved to future releases given capacity constraints in each of our specializations. 

  • Matt Chittle commented
    October 9, 2015 16:02

    In answer to the earlier request for title, Sn Dir of Products, our product team needs this function to perform what-if analysis for a very complex product line

  • Jamie Burr commented
    October 16, 2015 16:13

    As a Product Manager, I need to prioritize features across a product suite (ie a master release) based on capacity planning of the overall team. Development is responsible for building specific teams for products and features, where each product has its own release, but I am trying to organize them based on overall capacity. I think bring capacity planning to the Master Release level will allow me to do this. When looking at a feature board for a product, I would need to see committed and remaining capacities at the master release level instead of release level if the release belongs to a master release.

  • Chris Anderson commented
    January 21, 2016 13:15

    Agree, this is a critical feature that blocks acceptance of Aha at my company. Take a look at https://www.atlassian.com/software/jira/portfolio/demo for 'inspiration' :-)

  • Michal Anderson commented
    January 25, 2016 23:51

    Can you share when this is planned for?

  • Manolo Hernandez Kuri commented
    January 28, 2016 18:31

    Totally! We need to calculate capacity based on teamwork, and not linear based. 

  • mohan kannappan commented
    March 10, 2016 15:04

    me too

  • Cy Caine commented
    March 17, 2016 18:33

    Would love to know some best practices for using Aha while working through this (hopefully temporary) limitation. 

  • Jaclyn Fine commented
    April 1, 2016 19:18

    Product Management

  • Guest commented
    April 5, 2016 17:39

    Is there any release date set for this? The capacity and logging logic is somewhat broken at this moment :(

  • Tim Kress-Spatz commented
    April 13, 2016 14:05

    front end vs. back end teams

  • Jeff Patelczyk commented
    April 22, 2016 13:52

    This is the big missing feature in this product.  If you had this, I'd have zero issues getting probably 50 to 100 users added to my company.  We need to move beyond the excel spreadsheets and other cobbled together solutions and this is so close today.  

  • Christine Htoon commented
    April 27, 2016 19:10

    Please, please, PLEASE implement this. From a management perspective, this would be invaluable for resource planning.

  • Matthew Dwyer commented
    May 3, 2016 19:06

    We're struggling to plan for capacity of our design and engineering teams separately right now, so this will be a huge improvement if implemented. 

  • Bobby Land commented
    May 11, 2016 23:24

    Please implement this

  • Guest commented
    June 29, 2016 20:01

    I will throw my comment into the ring ... adding capacity vs estimate planning would be a big win for us with Aha because it would allow us to use 1 tool to plan products and projects.

  • Guest commented
    July 21, 2016 01:05

    A capacity planning dashboard would be good. Information radiator charts, a pre-set on that dashboard, would be a great value to POs planning this metric. So visualisation idea++

    Right now I need to create a special view in Features>List to be able to get information on what has been estimated, work done, logged effort etc. There is no visual view of this, except for the bar. If the capacity overflow, there is no way to tell by how much. One has to keep tweaking that number to get the right fit. This is cumbersome.

  • Pete T commented
    July 22, 2016 13:29

    +1 Critical feature

  • Sergio Martinez commented
    September 20, 2016 18:00

    Please add the feature

     
  • lucy liu commented
    September 23, 2016 17:18

    Please add these features, urgently needed!

  • lucy liu commented
    October 5, 2016 22:48

    it will be great if the following can be added to this :

    1. If I add a new milestone or phase which has a date that is beyond the original release date entered, the release date will be automatically updated.
    For example, the original release date was set 9/30/2016, and added a new milestone date 11/30/2016, and changed on of the phase date to 12/30/2016.
    The release date will be updated accordingly to reflect the new release date. 

    This can also solve some dependency issues.

     

  • Matt Vlasach commented
    October 19, 2016 17:48

    We have been able to move pretty much every other aspect of our product management process to Aha except this, which is still tracked in a fancy power point deck.  This would be huge for us, just to echo the others!

    This may be scope creep (not that anyone here is ever guilty of that), but being able to track a resource's vacation time in Aha would be subtly helpful as well.  I can't tell you how many times delivery plans have been screwed up because a resource's holiday was not accounted for during capacity planning.  I'm not looking for HR system integration, but some way for resources to (easily) mark their holidays so impact to capacity can be proactively managed.

  • Guest commented
    October 20, 2016 16:47

    Release time frame = 6 months... When is that starting from, definitely not when the idea was created?

  • Rodolphe M commented
    October 31, 2016 11:41

    An update to the capacity planning feature in aha is really needed.

    Capacity planning is the only pitfall I'm getting in using aha. I have a team working on several products, assigning a capacity on each release is unusable, so my plannings get inacurate and the whole aha usage is challenged by this feature lacking.

  • Ian Walter commented
    November 1, 2016 20:20

    As a new Aha user, this is greatly needed. It is very difficult to accurately plan if you cannot account for which engineers are working on what. (Keep in mind not all engineers are interchangeable, if only 2 people can implement a new data structure, we need to be able to account for that).

     

    Thank you!

  • Guest commented
    November 30, 2016 19:31

    Is there an update on the Release timing for this feature? We are so excited to have this capability at our fingertips as this is one of our biggest hurdles. Any update is greatly appreciated. 

  • Alex Met commented
    December 13, 2016 08:07

    Without Capacity for Design/Dev/Testing etc etc, Capacity planning is essentially useless, as it does not allow for good planning

  • Fabrice Gibelin commented
    December 13, 2016 15:13

    Agree with all above. Capacity planning as implemented is not usable. It's too bad because for a roadmapping tool it's a critical feature. For us it will probably mean phasing out aha when the time comes to renew the yearly subscription, as the widescale internal adoption of the tool depends on this.

  • Nigel Smith commented
    December 20, 2016 23:24

    Currently Lead Consultant (Agile Coach) at an Agile Consultancy. Former Delivery Manager, Product Manager, Project Manager, Developer, Tester.

    TL;DR: I decided not to vote for this because this undermines a teams ability to self organise. Its worth fostering self organisation because outcomes are better for customers and product. This feature will further lock you in to a way of working which discourages self organisation.

    To elaborate:

    Cross functional teams that have the capability and space to self organise are the ideal and best performing structure for a team delivering the ideas coming from product. Gather people with the skills needed to deliver a type of outcome, and give them the support to organise themselves to deliver those outcomes effectively. They are given the problems/opportunities and it is up to them to come up with the solution, making sure that it satisfies the needs of users. It takes a bit of coaching and support for a team to get to this place, and many of my clients start a long way from this position.

    This feature will undermine the ability for teams to self organise. If the team is divided by skills and their individual / skill type capacity is planned, they are being managed in what they do and when. This is bad from a team performance perspective.

    I can understand that if this is not the reality of how the team is working today. Having the ability to manage their capacity would actually help you to manage your delivery pipeline (though i can see some potential conflict with their workflow in jira). However, In my opinion and based on experience, it is undoubtedly worth going to the effort of fostering self organisation because the outcome for product and customers is far better.

  • Mandy Long commented
    February 8, 2017 15:50

    Are we still on track to see this feature in Q1 2017?

  • Kenny Czadzeck commented
    February 10, 2017 16:48

    Please implement this ASAP. Our organization needs it to justify continued use of Aha!, which we really enjoy otherwise.

     

    It's predominately used by our Product team and Project/Portfolio team, but the roadmaps are consumed at all levels of the company.

  • Samantha Hopkins commented
    February 15, 2017 23:28

    Help I need this my family is dying.

  • Guy Harris commented
    March 7, 2017 09:44

    This would probably allow Aha! to wipe out 50% of MS Project usage ... INCREDIBLY important.  

  • Mandy Long commented
    March 15, 2017 14:46

    Any update on this? We are starting the process of evaluating other vendor solutions because without this capability Aha is falling short for us. We want to stay! Please let us know when it will be released.

  • Max Cascone commented
    April 11, 2017 22:18

    Platform Product Manager

  • Katrina Scott commented
    April 26, 2017 15:37

    Is there any update on when this will be available? 

    We are considering becoming Aha! users but this is an important consideration. 

  • Etienne Poulin commented
    April 26, 2017 15:44

    At a minimum, we should be able to assign efforts to multiple resource types, assign each type with an average cost per day, and identify the available total capacity for each resource type with a start date / end date so Aha! could calculate the theoretical available capacity for each release. This issue actually impedes us from moving from an Excel-based capacity planning for the operational roadmap to fully embrace Aha! as the single product management tool we should use.

  • E S commented
    May 5, 2017 14:39

    We will need reporting capabilities across products and releases, as we are using the same resources for multiple releases concurrently.  Seeing the live data will improve planning tremendously.

  • Carsten Marx commented
    July 3, 2017 14:18

    Is a release date and an short overview for this awesome feature allready available?

  • Carsten Marx commented
    July 12, 2017 16:49

    Reminder: Is a release date and an short overview for this awesome feature allready available?

  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar
  • Gravatar