In order for the Team to provide a Commitment they need some way of estimating the work effort of the Product Backlog Items. To help teams determine their commitment level Scrum employs a rather unique way of estimating through a technique known as ‘Planning Poker’. Basically it works like this:
1. Each Team member (except the Product Owner) is given a deck of Planning Poker cards (that carry a value of between 0 and 200).
2. The team reviews each product backlog item and decides which is the smallest / least complicated item and assigns it a value (e.g. 2-points). It really doesn’t matter what units you use (it could be popsicle sticks for all that matters) as the estimates are all relative to each other.
3. Then, starting from the top the Team selects the first item from the product backlog
User stories that should be simple are frequently quite complex, written ambiguously, or have underlying needs that are hidden below the surface. Some should be broken up in to multiple stories. You may not know how best to write a user story and communicate needs. Many developers are not trained in the techniques needed to break through in this challenging environment and quickly get a clearer understanding of user needs.
Break Through Thinking
Make this break through: it’s not the designs you bring, or the solutions you suggest, that will clarify needs – it’s the questions you ask that determine how quickly a solution can be implemented. Good questions showcase your understanding and build trust between you and the user. Here are a few situations where a few great questions will help you deal with difficult user stories and difficult times:
Determining the success criteria
Here is a simple approach to clarifying user stories: attach your clarifications as acceptance criteria or test conditions. The user story could be all about the user interface. The success condition in the mind of the user could be very different “A user can buy our product.” By focusing on the outcome not only is the capability needed clearer, but you also now have a clear understanding of what to focus on with users during sessions.
Four simple tests to assess if requirements are not done
These are Business Requirements level tests that work and will improve your requirements quality irrespective of delivery methodology:
If the requirements lack context: Requirements always exist to support “what” the business wants to do, not “how” it wants to do it. The “what” part of this is the context of business process. Lack of understanding of what business processes are impacted by requirements means someone has no idea of how requirements impact each other, the impact of removing requirements, or the ability to assure that the requirements collectively are complete or will meet a specific business objective. The way a company applies context in its documentation also creates the structure of the documentation.
If the interdependency is not evident: How do you look for proof that interdependency is documented? Look for a section in the material called “dependencies”, check the “issues list”, and look for an analysis technique called a context diagram (every line on a context diagram is an interdependency). Why is interdependency so important? There are two aspects to scope: internal to the system (e.g., its functionality, the workflow and information flow, etc), and external to the system (e.g., how this system needs to interact with other systems, how the workflow being automated hands off across other departmental units). In the absence of knowing the interdependencies, you only ever know part of the story on scope, so it becomes probable that you will encounter significant scope shift on any system of any degree of complexity.
Unclear business objectives: Objectives must be Specific, Measurable, Achievable, Results-oriented, and Time-bounded (easy to remember as ‘SMART’). The absence of objectives eliminates the ability to assess solution tradeoffs, makes difficult the prioritization of functionality, and other problems. You can test if a particular function meets needs with user acceptance tests. You cannot test if the collective system meets needs unless you have clear objectives.
The concept of capability maturity has been around since Deming first started the quality movement in the 1950s. So what’s a “mature” business analyst? Are we really looking for grey hair and wrinkles to determine that individuals or collective organizations are consistently going to perform at a high level of quality? Is there some measure of “prune-i-ness” that you can use to pick out top performers?
I think not.
Overall, if an organization wants to change the performance level of its business analysis function, it has to focus on six underlying capabilities: processes, practices, people, technology, organization and deliverables. Sure, you can get a short term bump in productivity by being draconian, but it is simply not possible to make material, sustained change without systematically addressing these six capability areas. The question in each of the six areas is not whether you have, for example, processes or not. The question is the degree to which an organization accepts and adopts that process as the best possible way of doing things. This means that some organizations think they have a process for requirements definition and management … but admit it’s actually quite ad hoc. At the other end of the spectrum, organizations have institutionalized the process, and can describe their efforts to continuously optimize this process so that it’s alignment to delivering stakeholder value is maximized. These two examples are the extremes of requirements definition and management maturity.
There are four situations where companies should strongly consider and investigate outsourcing the Requirements Center of Excellence (RCoE):
1. Growing very rapidly: Where a company is growing very quickly, increases in productivity translate into direct cost savings. Any improvement made in application time-to-market is critical to the organization. High growth companies can leverage the outsourcer to bring mature processes that simply could not be contemplated given the stress on the internal organization for growth.
You have to admit – agile folks are conflicted. On one hand there’s the folks screaming requirements are dead***. On the other hand, people teaching agile practices have to explain the asterisks; mention these things called user stories and the practices of getting good user stories (like making each user story testable and how to deal with non-functional requirements). Then there are the folks rolling out these practices and using them in real life on complex engagements. We’re facing the issues of sequencing and redundancy of stories, figuring out which ones accidentally change the architecture of the system (oops!), which ones were really a whole book rather than just a story, etc. and how to actually get to the promised land of higher productivity. No wonder you get questions from developers like, “can I write down this non-functional requirement?” Agile is still a storm of mixed messages – and like the Internet bubble of the late 90s hype might do more harm than good to the movement over time.
High requirements maturity translates directly to IT spending efficiency. These efficiency advantages become more pronounced as the size and complexity of projects grow. By investing in requirements maturity, organizations can not only improve business analysis capabilities, but also reduce IT spending waste. This means a greater level of certainty and higher success rates for all IT development projects.
Click here for more on Requirements and Business Analysis
Track IPhone unique and for this reason can you track an iphone without special. I think that information interesting. Remember that. Also you will have no problems.