User stories - WHO wants them, WHAT are they and WHY use them?

User stories are a popular technique for capturing high-level requirements. User stories provide the rationale and basic description of a new feature request. The following format is the most recognizable user story template:

As a <WHO>
I want <WHAT>
So that <WHY>

Agile teams adopting the user story technique often struggle with questions such as: WHO are user stories produced for? WHAT do good user stories look like? WHY maintain user stories instead of more detailed requirement specifications? To answer these questions – I will recycle the who/what/why template of user stories.

WHO WANTS USER STORIES?

• Project stakeholders: these individuals want an easy method to pin ideas to the product backlog. With user stories - ideas don’t need to be defined in detail – the user story will provide a “placeholder for a conversation”.
• The end user: teams that are able to elicit requirements directly from end users can use this technique to facilitate the discussion and documentation of feature requests. What does the user want to do? Why?
• Project Manager/Product Owner: when grooming the product backlog – user stories are much easier to prioritise than detailed requirement specifications. User stories provide a non-technical, concise summary for the product team to decide the primacy of a feature.

WHAT ARE USER STORIES?

• Definition: User stories describe the desired interaction/dialogue between a user and the system. User stories provide the user’s rationale for a feature.
• Typical format:
  
  1. AS A [actor/user role] – this can be referred to as the WHO section. Who wants this feature? The user could be a generic actor (e.g. AS A user of the website), or a specific user role (e.g. AS A frequent business traveler), or even another system (AS A BACS payment system). Actors can be identified by internal discussions within the project team – identifying user roles may require more sophisticated analysis (e.g. profiling activities by the marketing department, transaction analysis, industry segmentations etc).
  2. I WANT [feature/action] – this can be referred to as the WHAT section. What does the user want? The user will typically want the system to perform a new behaviour e.g. I WANT the ability to track an order, I WANT to pay for orders using an AMEX card, I WANT to cancel an order without any hassle.
  3. SO THAT [benefit] – this can be referred to as the WHY section. Why does a user want this functionality? This section provides the justification/benefit of the feature.

• Characteristics of good user stories: the INVEST acronym is frequently used to describe attributes of a good user story:
  1. Independent
  2. Negotiable
  3. Valuable/Vertical
  4. Estimable
  5. Sized Appropriately/Small
  6. Testable

WHY USE USER STORIES?

• Requirements as an emergent property: user stories provide the Business Analyst with a springboard for analysis. A single user story (e.g. AS A price sensitive user, I WANT to be able to cancel my order, SO THAT I do not get charged by the bank for exceeding their overdraft limit) can lead to multiple scenarios for the BA. What is the happy path of this user story? What are the edge cases (e.g. what if some of the items were reduced as part of a promotion)? What are the business rules (e.g. full refunds are only provided up to 3 days from when the transaction was processed)? Requirements should emerge from user stories (not vice versa) - all requirements should have a user justification.
• Maintenance of the backlog: the detail of a feature is abstracted a level below user stories. In addition – user stories should have few/no dependencies (refer to the INVEST acronym) – this means that user stories are lightweight additions to the product backlog and are therefore easy to maintain.
• Available for discussion: user stories should be understandable by business users/end users/developers/all team members. User stories facilitate cross-role discussions and encourage open communication between various project silos.
• Trees and forests: Working at a detailed level can occasionally mean that some requirements are not identified. User stories provide a way to mitigate the probability that user journeys are missed by the team.

User stories provide the team with a method to capture and discuss high-level requirements. Good user stories follow the INVEST acronym and provide the user’s justification for a new feature. Within Scrum/Agile teams – user stories provide an abstraction of requirement details – this facilitates maintenance of the backlog and provides the team with a “placeholder for a conversation”.

Hybrid Memory Cube spec makes DRAM 15 times faster

The three largest memory makers - Micron, Samsung and Hynix; announced the final specifications for three-dimensional DRAM, which is aimed at increasing performance for networking and high-performance computing markets. The technology, called a Hybrid Memory Cube (HMC), will stack multiple volatile memory dies on top of a DRAM controller. The DRAM is connected to the controller by way of the relatively new silicon VIA (Vertical Interconnect Access) technology, a method of passing an electrical wire vertically through a silicon wafer.

The logic portion of the DRAM functionality is dropped into the logic chip that sits at the base of that 3D stack. That logic process allows to take advantage of higher performance transistors ... to not only interact up through the DRAM on top of it, but in a high-performance, efficient manner across a channel to a host processor. This logic layer serves both as the host interface connection as well as the memory controller for the DRAM sitting on top of it. The DRAM is broken into 16 partitions, each one with two I/O channels back to the controller. Each Hybrid Memory Cube - there are two prototypes - has either 128 or 256 memory banks available to the host system.

The first Hybrid Memory Cube specification will deliver 2GB and 4GB of capacity, providing aggregate bi-directional bandwidth of up to 160GBps compared with DDR3's 11GBps of aggregate bandwidth and DDR4, with 18GB to 20GB of aggregate bandwidth.

The Hybrid Memory Cube technology solves some significant memory issues. Today's DRAM chips are burdened with having to drive circuit board traces or copper electrical connections, and the I/O pins of numerous other chips to force data down the bus at gigahertz speeds, which consumes a lot of energy. The Hybrid Memory Cube technology reduces this task to make the DRAM drive only tiny TSVs which are connected to much lower loads over shorter distances. A logic chip at the bottom is the only one burdened with driving the circuit board traces and the processor's I/O pins.

The interface is 15 times as fast as standard DRAMs, while reducing power by 70 percent! The beauty of it is that it gets rid of all the issues that were keeping DDR3 and DDR4 from going as fast as they could. For example, instead of having multiple DIMMS (which can range from one to four) on a motherboard, you would need only one Hybrid Memory Cube, cutting down on the number of interfaces to the CPU.

The HMC has defined two physical interfaces back to a host system processor: a short reach and an ultra-short reach.
The short reach is similar to most motherboard technologies today where the DRAM is within eight to 10 inches of the CPU. That technology is aimed mainly for use in network applications and has the goal of boosting throughput from as much as 15Gbps to 28Gbps per lane in a four-lane configuration.
The ultra-short reach interconnection definition is focused on a low energy, close-proximity memory design support of FPGAs, ASICs and ASSPs, such as high-performace networking, and test and measurement applications. That will have a one to three-inch channel back to the CPU, and it has the throughput goal of 15Gbps per lane.

Link: http://www.infoworld.com/d/computer-hardware/hybrid-memory-cube-spec-makes-dram-15-times-faster-215620