Regular sessions with Product Management and Customers

One of the most common experiences I had while interacting with people on product development teams, especially those who have been on 2-3 development cycles, from start to end is, that they seem to get a feeling for what the features in the product should be, how the workflow should happen and so on. It can get tricky when they have a strong feeling in this regard since they might incorporate their feelings in the workflow that they are implement and it would take some effort by the workflow designer or the product manager to get the design as they want (may not happen very often, but it is something to be watched out for).

But when you get the team members on the beta release program, or to monitor the user forums, or to attend sessions where actual product users meet the product development team, it can get interesting. Even when team members get to review the prerelease program (the beta program), they can seem surprised at the type of defects or feature requirements that come through these programs. I have seen cases where the team members almost dismiss these as defects that are worthy of deferring or not part of the general workflow and they have to be reminded that these are actual users, the ones who actually pay and use the software program.

The more perceptive of the team members welcome such interactions, since it gives them a great idea of how their customers are actually using the product (or atleast a section of the users) and the more they take part in their interactions, the more they are connected with how the users actually use the software and this in turn benefits the product since they are more attuned to the requirements of the user, and in fact, would actively hunt to figure out the requirements of the user.

At the same time, it is necessary that all members of the team are exposed to such interactions. Such interactions help team members understand what the users feel, that sometimes their perception of what users feel and what they themselves feel about how a feature should be like, or the severity of a defect can vary drastically, and such interactions help reduce these differences and give them a better understanding of the customer perception of what is important for features. The next when a new feature is being designed, it makes the process much smoother, and actually helps the product manager - for the case of teams that implement the Scrum development methodology, such a customer centric perception from the team members is absolutely essential and helps to drive the process of feature delivery. 

One example of this was where the feature requirement was detailed by a customer to the product management team who wrote feature specifications for the development team. However, the developer was a senior developer who had his own ideas of what the ideal feature should be like and proceeded to tweak the feature specification. It required some amount of rework to ensure that the feature was finally done as per the product management / customer requirement. 

Encouraging a creative team member to assist in the UI designer duties

There are a certain number of resources that any particular software team can have assigned to them. Based on the amount of work that is under consideration of the team, the needs of the team are estimated in terms of the developers and testers vs. the amount of work done. If there is a lot of work and there are not enough developers or testers needed for this quantity of work, then the team has only 3 choices:
- Ask for and get more testers and/or developers, and take on this quantity of work
- Ask for and not get more testers and/or developers, and decline work beyond the amount that can be done with the team that you have
- The third one is the most problematic. The team does not get additional testers or developers, but there is a lot of pressure built to take on the additional work. One would not like to think of such a scenario, but it does happen, and eventually the team either gives up the additional work or takes on a lot of stress, and maybe even has a reduced quality in terms of their deliverable.
However, twice in the past 4 years, we have come across a situation which is not easily solvable, and for which we did not get any additional support. What was this case ? This was the case where the release we were doing had a number of features that required the support of a workflow designer / UI designer. In a typical release, we have a certain number of such resources assigned to the team, based on an expectation that the amount of workflow and UI required will be of a certain % (let us assume that 60% of the work being done by the team needs the support of the workflow / UI team - the reason for it being 60% is that the remaining 40% is where the team does some kind of tweaking / modification which does not require any workflow changes or UI changes).
However, this gets badly affected when there was a release where the estimation of the amount of work where the workflow / UI designer is needed was around 80%, and it was pretty clear that the team that was doing the workflow / UI design was not staffed for this extra work, and even if we had got allocation of budget for the extra work (which was not 100% certain by itself), it takes months to hire somebody with this skill set. Hence, there was no getting around the fact that we had a puzzle on our hands - we had estimated work for which we had enough developers and testers, we did not have enough designers. What to do ?
When we were discussing with the senior members of the team, we came across an interesting suggestion. Over the past, the team had noted that there were some members of the team who were more easily able to comprehend the designs put out by the designer team and understood the way that they were doing their reasoning. Given that we really did not have a choice, we went ahead with the open offer to team members who wanted to give open flow to their creative juices, and prepare the design, with rounds of review by the designer team (we found that this amount of effort could be accommodated), and then present to this team. One of the main persons we expected did not volunteer, but another person who was also seen a prospect volunteered, and we pulled her off her current responsibilities and got her temporarily assigned to the designer team. Over the next few weeks, we did a close watch on this arrangement, and while it was not as good as the design done by the designer team, our Product Manager was satisfied with this, and so was the design team, and we went with the design that she produced and the team accepted. Now, this was not a long term arrangement, but in the scenario described above, it seemed to work. 

Getting everybody on the team to do some testing - helps in understanding the process

This is a common topic for everybody that works on a software product or on a software project. Every product has a testing team (although the reporting structure of the team can vary from products where the testing team works as an independent team, or the team can report into the overall manager of the project), but the focus of the post is on a specific phrase called 'everybody tests'. The testing team is the last and probably the only major element in the entire project (leaving aside the processes such as design reviews and unit testing) that controls the quality of the product, and everybody should have a stake in their success. However, this is easier said than done. Many a times when there is some kind of struggle regarding the amount of time available for a product, the thought has gone towards the amount of time dedicated to testing, and whether can be some kind of compromise.
I would like to showcase my experience. I am not on the testing team, but have a good idea of the kind of effort it takes, as well as the amount of time it takes to reach a phase where the testing has come to a completion and a large percentage of the defects have been removed. However, this is one of the biggest problems - there is no such thing as 100% testing, and it can become extremely critical for people to understand that. One of the best ways of doing that is to experience the testing environment and also go through some of the pains involved with the entire testing process.
So, I had the designation of something called a Product Specialist, and my job was to determine the business requirements and provide those in the form of requirements to the development team, work with the team to ensure that those got done and interact with users for training and other purposes. There was a level of understanding of the product that was adequate for my work, but if you asked me, there were levels of complexity in all the workflows that I did not possess. Further, there was always a level of impatience regarding the time-frame it took the development team to get the work coded, and a higher level of impatience regarding the time it took for testing.
However, at a certain phase, we all were way behind in our schedule, and all the non-testing team members were asked to do integration and acceptance testing (we were not qualified to do the system testing part). This was the first time I was doing testing, and the process of ensuring that data was available, of looking at the test cases and selecting the ones for a greater detail of testing, and then the entire process of testing, all these gave an entirely new perspective to the process of testing for me. I had the same feeling as a testing team would get when somebody from the development team would query and deny a defect I found or treat it as a low level of defect that did not really need a fix, and so on. Overall, this experience lasted 2 weeks, and provided me a perspective into the testing process that I never had earlier. An additional benefit was about getting a much higher level of learing of the various workflows in the areas that I was testing. As a result, as I moved into positions of project management, I would always have discussions about ensuring that everybody in the team was asked to do some level of testing, even if they were very busy.
Even if a developer was doing testing, it provided them an invaluable experience of seeing how the feature workflows behaved, and how sometimes even small things can get critical to users if it serves to hinder their workflows in some way. And this is only one of the advantages of having a developer or another role in the team doing the testing.

When to re-estimate? What is a better way to estimate : Story points or Ideal Days?

When to Re-estimate?

Story points and ideal days are estimates of the size of a feature which helps you to know when to re-estimate. Re-estimate is done only when your opinion of the relative size of one or more stories has changed. One should not re-estimate just because progress is not coming as rapidly as expected.

Velocity should be allowed to take care of most estimation inaccuracies. Velocity is considered to be a great equalizer. The reason behind this is that the estimate for each feature is made relative to the estimates for other features, it does not matter if our estimates are correct, a little incorrect, or a lot incorrect. What matters is that they are consistent. As long as we are consistent with the estimates, measuring velocity over the first few iterations will allow us to have a reliable schedule.

At the end of an iteration, it is not recommended giving partial credit for partially finished user stories. The preference is for the team to count the entire estimate towards their velocity (if they completely finished and the feature has been accepted by the product owner) or for them to count nothing toward their story otherwise.

However, the team may choose to re-estimate partially complete user stories. Typically, this will mean estimating a user story representing the work that was completed during the iteration and one or more user stories that describe the remaining work. The sum of these estimates does not need to equal the initial estimate.

A team can choose to estimate either through story points or ideal days. Each has its advantages.


Benefits of Story Points
1. They help drive cross functional behavior.
2. The estimates derived by story points do not decay.
3. Story points are a pure measure of size.
4. Estimation through story points is faster.
5. Unlike ideal days, story points can be compared among team members. If one team member thinks that it will take him 4 ideal days, and another member thinks that it will take him 1 ideal day, both of them may be right yet there is no basis on which to argue and establish a single estimate.

Benefits of Ideal Days
1. They are more easily explained to those outside the team.
2. They are easier to get started with.

The advantages of story points are more compelling as compared to benefits of ideal days. one way is if a team is struggling with estimating the pure size, they can start off with estimating with ideal days and gradually switching to estimating by story points.